Skip to content

DocsStart

2 min read · updated

Build a request

Turn a backend decision into a text, a question and its possible answers. Read the result and keep the application action in your own code.

Ask a small question your application needs answered, such as which queue should handle a ticket. With a server running, this checks the service and asks one choice question:

curl --fail-with-body -sS --max-time 60 http://127.0.0.1:8000/v1/systemone \
-H 'Content-Type: application/json' \
-d '{
"state": "My card keeps getting declined when I renew.",
"questions": {
"category": {
"type": "choice",
"instructions": "Which team should handle this ticket?",
"criteria": {
"billing": "Invoices, payments and refunds",
"access": "Login, passwords and permissions",
"bug": "The product behaves wrongly"
}
}
}
}'

Run against the CPU stand-in at v0.46.0 on 2026-11-13: the answers are the stand-in's, not the default model's.

Download this request as JSON for your client.

Figure · Illustrative field map

Find the field your code sends or reads.

Request

{
  "state": "My card keeps getting declined when I renew.",
  "questions": {
    "category": {
      "type": "choice",
      "instructions": "Which team should handle this ticket?",
      "criteria": {
        "billing": "Invoices, payments and refunds",
        "access": "Login, passwords and permissions",
        "bug": "The product behaves wrongly"
      }
    }
  }
}

Answer fields

{
  "answers": {
    "category": {
      "type": "choice",
      "choice": "billing",
      "probabilities": {
        "billing": 0.8,
        "access": 0.05,
        "bug": 0.15
      }
    }
  }
}

The text, question, options and typed answer are separate parts of one decision.

Read all field explanations
Text
state is the text to ask about. Keep it separate from the question.
Question
questions names each judgment. Its type and instructions tell the server what to answer.
Options
criteria gives named options for choice or ordered levels for score. A noul question already has yes and no, and can optionally describe true and false.
Answer
answers uses your question names. Read the typed value and its probabilities before your application acts.

Illustration: chosen probabilities, using the tutorial request. Your model returns its own values.

Put the message, document or record you want evaluated in state. Keep the question and your instructions separate from that text. For example, the ticket describes the customer’s payment problem; the question asks which team should handle it.

Each key under questions is a name your code chooses, such as category. Its answer comes back under the same key in answers. Write one judgment per question, and add more named questions when you need separate judgments about the same text.

For a choice question, criteria maps your option keys to descriptions, or to null when the names are enough. Choose distinct keys that your code can use directly, and write descriptions when neighboring options need a clear boundary. For example, distinguish a failed payment from a login failure rather than asking the model to invent a category.

Choose a question type compares a choice, a yes or no question and an ordered score.

For this request, read answers.category.choice for the selected option and answers.category.probabilities for its distribution. Your application maps that option to a queue or a review workflow. For automatic decisions at an error target, use a certified task and require both certified: true and certificate_kind: "gold" on its answer.

  • A successful request returns answers under the names you supplied; check the HTTP status before reading them.
  • A field called model does not switch the model loaded by a decisio server.
  • A probability threshold you choose by hand is a routing rule, not a certificate.

Install the decisio skills to have Claude Code or Codex prepare your setup, request or backend integration. Choose the workflow for your task and include your hardware or endpoint in the prompt.