Ask yes or no

Use a yes or no question to check one condition, such as whether a customer explicitly asks for a refund. With a decisio server running, paste this request into a terminal:

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": {
    "refund": {
      "type": "noul",
      "instructions": "Does the customer explicitly ask for a refund?"
    }
  }
}'

Run against the CPU stand-in at v0.46.0 on 2026-11-13: the answer is the stand-in's, not a model-quality measurement.

Download the request as JSON to reuse it in your own client. This example uses the decisio endpoint; Ollama’s guide gives its port and required model name.

Ask one clear question

noul is the API’s name for a yes or no question. Write the condition in instructions; the key refund names the answer your code will read. This question asks about an explicit refund request, rather than assuming every payment problem needs a refund.

You can describe the two sides with optional criteria keys true and false when they need more explanation. For unrelated conditions, such as a refund request and a security incident, add separate named questions.

Read the probability of yes

Read answers.refund.noul from the JSON response. These illustrative fields use a chosen value, rather than a measured model result:

{"type": "noul", "noul": 0.1}

A shape to fill in, not a command to run.

The probability of yes is 0.1, and the probability of no is 1 - 0.1, or 0.9. The answer is a number, not a Boolean. A value near 0 means likely no, a value near 1 means likely yes, and a value near 0.5 gives little separation.

Figure · Yes or no

The answer is the probability of yes; no is the remainder.

Yes

0.10

No

0.90

noul = 0.10. Your code decides when to act on yes, on no or on neither.

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

Explore the request and answer fields

Figure · Illustrative field map

Find the field your code sends or reads.

TextQuestionOptionsAnswer

Request

{
  "state": "My card keeps getting declined when I renew.",
  "questions": {
    "refund": {
      "type": "noul",
      "instructions": "Does the customer explicitly ask for a refund?"
    }
  }
}

Answer fields

{
  "answers": {
    "refund": {
      "type": "noul",
      "noul": 0.1
    }
  }
}

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.

Keep a review path

Your application chooses when to act on yes, when to act on no and when to ask for review. For example, it could flag a refund request when the probability of yes is at least 0.9, mark no refund request when it is at most 0.1, and review the middle. Those are illustrative policy lines to evaluate on your data, not error guarantees.

Check the HTTP status first, and send service failures to your application’s fallback. Use the probabilities shows how this policy differs from a certified task.

Good to know

• Test the numeric value explicitly. In Python and JavaScript, a nonzero probability is truthy even when no is likelier.
• For a decision to act on no, use 1 - answer.noul as the probability of that side.
• A certified task can support automation at an error target; a threshold chosen by hand does not certify an answer.

What next

• Choose an option: select among several named outcomes.
• Rate on a scale: express ordered impact or quality.
• Use the probabilities: build an explicit review policy.