AI Strategy

The Three Questions a Decision Model Can Answer

Every decision an AI can make for you in software reduces to three shapes: choose from a list, rate on a scale, or verify yes-or-no. A plain-English guide to the three decision shapes, with examples and when to use each.

By Dr. Sanju Abraham 13 min read
Every decision a decision model can make for you fits one of three shapes: choose, rate, or verify.

By Dr. Sanju Abraham, Fractional CTO — 180+ projects shipped, 34 funded companies. Published September 30, 2026.

Key takeaways

  • Every decision an AI can make for you reduces to three shapes: choose (pick one from a list), rate (score on an ordered scale), verify (how likely a yes-or-no is true).
  • Choose returns a label from a bounded set. “Which department handles this ticket?”
  • Rate returns a number on a defined rubric. “How urgent is this, from 1 to 5?”
  • Verify returns a probability between 0 and 1. “Does this need a human to review it?”
  • Every real-world decision workflow — ticket routing, lead scoring, fraud flags, moderation, extraction — composes those three shapes.

The short answer: A decision model is an AI that returns a typed value instead of a paragraph. Every question you can ask one fits into one of three shapes: choose one from a list, rate on a scale, or verify how likely a yes-or-no statement is. Different vendors wrap these in different names — Jev calls them Choice, Score, and Noul — but the underlying trio is universal. Learn these three shapes and you have the whole surface area of what a decision model can do.

Someone on your team wants to add AI to a feature. The conversation inevitably reaches, “But what can it actually do?” If the AI in question is a decision model — the quiet kind of AI that returns a value instead of a paragraph — the answer is unexpectedly simple. It can do three things. That is it. The rest is just composition.

This piece walks through all three, in plain English, with concrete examples and a short decision tree for picking the right one.

What are the three questions a decision model can answer?

A decision model answers one of three question shapes at a time. Every real-world workflow is built by composing them. Here is the simplest possible description of each:

  • Choose: “Which one of these N options fits best?” Returns a label from a list you defined.
  • Rate: “On this scale, where does this fall?” Returns a number inside a rubric you defined.
  • Verify: “How likely is this yes-or-no statement to be true?” Returns a probability between 0 and 1.

That is the whole grammar. Every ticket routing engine, every lead scorer, every fraud flag, every content moderator, every invoice extractor you have ever used is built out of some combination of those three. If a question cannot be expressed as one of them, a decision model is not the right tool — and that is a feature, not a bug. For the broader framing of why structured AI output beats chat output on these problems, see our companion piece on not every AI needs to talk.

CHOOSEPick one from a listQuestion”Which department?”BillingTechnicalSalesOtherReturns”Billing” (0.96)RATEScore on a defined scaleQuestion”How urgent, 1–5?“12345Returns4 (0.88)VERIFYProbability a yes/no is trueStatement”Needs human review?”YES0.0 — — — — — 1.0Returns0.91
The three universal decision shapes. Every real-world decision workflow is built by composing them.

1. Choose: pick one from a list

Choose answers “which one of these?” You give the model a specific, bounded list of options, and it returns one of them, plus a confidence number.

The classic examples live in support and routing. “Which queue should this ticket go to?” Returns "billing" from the set {billing, technical, sales, other}. “Which category does this expense belong to?” Returns "travel" from your chart of accounts. “Which language is this document in?” Returns "es" from a list of ISO codes.

Three things to remember about Choose:

  • The list has to be finite and defined up-front. “Which category?” with no list is a prose question, not a Choose question. If the model has to invent the option it is picking from, you are not using a decision model — you are using a chatbot that happens to return short text.
  • Confidence matters. A Choose answer always arrives with a probability score; code can route low-confidence picks to a human reviewer the same way it routes high-value transactions.
  • Mutual exclusion is implied. If a ticket legitimately spans billing AND technical, Choose will force one. Use multiple Verify questions in parallel instead (“Is this a billing issue?” / “Is this a technical issue?”) so each gets its own probability.

Choose is the shape that replaces 80% of the simple if/else logic you would otherwise write with hand-tuned keyword matches.

2. Rate: score on an ordered scale

Rate answers “how much?” You give the model a rubric — a 1–5 star scale, a 0–100 score, a low/medium/high ordinal — and it returns a value inside that rubric, plus a confidence number.

Rate shows up anywhere you want a graduated signal instead of a boolean. “How urgent is this ticket, from 1 to 5?” “How well does this candidate match the job description, 0 to 100?” “What is the risk score for this transaction, low / medium / high / critical?” “How polished is this draft, 1 to 10?”

Three things to remember about Rate:

  • The rubric lives in the prompt. The model does not know what “4 out of 5” means until you spell it out. Rubrics with example anchors (“5 = critical, pages on-call; 4 = urgent, same-day reply; 3 = normal”) outperform a bare “1 to 5” every time.
  • Pick a scale with enough gradation to be useful. But not so much it becomes noise. 1–5 and 1–10 are good defaults. 1–100 only works when the thing you are rating has that much real variance.
  • Rate pairs beautifully with thresholds. “Act automatically above 8. Queue for human review between 5 and 8. Escalate below 5.” One line of code; one AI call; the rest is normal software.

Rate is how you build a dial, not a switch. For a longer treatment of the economics of letting software grade things, see our take on an AI strategy for SMB owners that survives contact with reality.

3. Verify: how likely is this yes-or-no?

Verify answers “is this true?” You hand the model a specific yes-or-no statement and it returns a probability between 0 and 1 — not a label, not a hedge, a number.

Verify is the shape most teams underuse, because they default to Choose whenever they see a boolean problem. The two are not the same. Choose makes a hard pick between options; Verify gives you a measured probability you can threshold.

Everyday Verify questions: “Does this email ask for a refund?” “Does this transaction look like card testing?” “Is this comment hateful?” “Did the candidate confirm they are available to start by October?” “Does this invoice show a vendor we have paid before?”

Three things to remember about Verify:

  • One statement per call. “Is this urgent and does it contain PII?” is two Verify questions, not one. The model will give you a cleaner answer if you ask them separately.
  • It is a probability, not a classifier. 0.72 means “there is a reasonable chance this is true, but it is far from certain.” Your code should treat 0.5 as a flip of a coin, 0.9 as “act,” 0.3 as “act on the negative,” and the middle as “ask a human.”
  • Parallel Verify questions are how you build multi-label systems. A user-generated post can be hateful, spam, and off-topic simultaneously. Three Verify calls, run in parallel against the same text, each returns its own probability. Easier to tune, easier to test, easier to monitor drift on.

Verify is the shape that quietly powers most modern moderation, fraud detection, and extraction pipelines. Products as different as Stripe Radar, Gmail spam filters, and content moderation at scale all boil down to vast grids of Verify questions.

How do you combine the three in a real workflow?

Most real workflows use all three shapes together. Here is one concrete example — triaging an inbound support email — walked through end to end.

A customer sends in a message. Your software fires one API call to a decision model with four questions bundled against the email body:

  • Choose: “Which queue? [billing, technical, sales, other]”
  • Rate: “How urgent, 1–5?”
  • Verify: “Does this request a refund?”
  • Verify: “Does this mention PII that needs redaction?”

The model answers all four in parallel and returns a typed response. Your code reads the fields and acts: route to the queue, mark the urgency, flag the refund for retention, and strip the PII before storing. The whole thing is one network call and about twenty lines of application code. No parsing. No prompt-engineering gymnastics. For the deeper side-by-side on why this works so much better than asking a chat model to write a paragraph, see chatbot vs decision model: what’s the difference?

The pattern generalizes. Lead scoring blends Rate (“quality 0–100”) with one or two Verify guards (“is this a competitor?”, “is this a student?”). Invoice extraction blends several Choose questions (“vendor type?”, “currency?”) with Verify flags (“is this reimbursable?”) and a Rate sanity check (“confidence in total amount, 1–5”). You compose; the model answers.

A real triage workflow composes all three shapes in a single call: one Choose for the queue, one Rate for urgency, two Verify flags for refund and PII.

Which decision model products offer these three questions?

Every serious decision model on the market exposes some version of the same three shapes, under its own vocabulary:

ProductChooseRateVerify
TypeSafe AI’s JevChoiceScoreNoul
OpenAI Structured OutputsJSON Schema enumbounded numberboolean + confidence
Anthropic strict tool usetool-input enumtool-input numbertool-input boolean
Google Gemini responseSchemaenum fieldbounded number fieldboolean field

The names and syntax differ. The three questions you can ask do not. If you learn to think in Choose / Rate / Verify, you can move between any of these products in an afternoon.

What can a decision model NOT answer?

The three shapes are powerful specifically because they are narrow. The things decision models cannot do are the inverse of that narrowness:

  • Open-ended generation. “Draft a reply to this customer.” That is a chat problem.
  • Multi-step planning. “Figure out what to do about this and then do it.” That is an agent problem.
  • Novel category invention. “Make up a new label that captures this group of messages.” Choose can only pick from a list you supplied.
  • Explanations as the deliverable. “Explain the reasoning behind this decision in a paragraph a human can audit.” A decision model can include a one-line reason field in its schema, but it will not write an essay.

If your use case needs any of those, reach for a chat model or an agent framework and come back to the decision model for the specific sub-step where a label, score, or probability is the deliverable.

Frequently asked questions

What are the three questions a decision model can answer?

A decision model answers questions in one of three shapes: Choose (pick one from a bounded list of labels), Rate (score on an ordered rubric like 1–5), or Verify (how likely a yes-or-no statement is to be true, returned as a probability from 0 to 1). Every real-world decision workflow is built by composing those three shapes.

How is a Choose question different from a Verify question?

A Choose question picks one label from a mutually-exclusive list — “which queue?” with options {billing, technical, sales}. A Verify question returns a probability for a single yes-or-no statement — “is this a billing issue?” The practical difference: Choose forces one answer; Verify lets a message be flagged by multiple parallel questions at once.

Can one decision model call answer all three shapes at once?

Yes. Modern decision models — including Jev, OpenAI Structured Outputs, and Anthropic strict tool use — let you bundle multiple questions against the same input and answer them in one parallel pass. A support ticket triage call might contain one Choose, one Rate, and two Verify questions and return all four answers together.

What is a good rubric for a Rate question?

A good Rate rubric spells out what each level means with a short anchor: “5 = critical, pages on-call. 4 = urgent, same-day reply. 3 = normal, this-week reply. 2 = low, next sprint. 1 = ignore.” Without anchors, the model guesses what “4 out of 5” means to you, and the guess drifts over time. Anchors keep the scale stable across prompt and model changes.

Which decision model API should I start with?

Start with the API your team already has credentials for. If you are already on OpenAI, use its Structured Outputs. On Anthropic, use strict tool use. On Google, use Gemini’s responseSchema. If you want a model built from the ground up for decisions and nothing else, start with Jev; see our Jev explainer for the full product take.

Can a decision model handle open-ended questions?

No, and that is the point. Decision models return typed values from bounded sets by design. An open-ended question like “draft a reply” or “explain the reasoning here” is a chat problem, not a decision problem. For a breakdown of when each is the right tool, see chatbot vs decision model: what’s the difference?.

How do I pick between Choose, Rate, and Verify for a given question?

Ask what the answer looks like. If the answer is “one of these N options”, use Choose. If the answer is “a number on this scale”, use Rate. If the answer is “a yes-or-no, with a probability I can threshold on”, use Verify. Most non-trivial workflows need two or three of these in the same call.


If you are mapping an AI feature right now and the shape-by-shape decomposition is starting to feel bigger than one afternoon, that is exactly the per-call-site judgment a Fractional CTO is paid to make. One hour spent on the right decomposition can save a quarter of engineering time. More pieces on this thread live in the AI Strategy archive.

  • #decision-api
  • #ai
  • #architecture
  • #builders
  • #primitives

Need a CTO without the headcount?

Schedule a 30-minute intro call. We'll listen first, recommend second.