Decision model definition

A decision model in AI answers a typed question instead of writing text: it returns a choice, a score, or a probability that code can act on immediately, along with how confident it is. Its accuracy depends heavily on the state it is handed, and it degrades when that state is padded with material the question does not concern. In Sanity, a GROQ projection returns only the fields you name, so the state behind a decision question can be the one block it concerns rather than a whole document.

What is a decision model in AI?

A decision model is an AI model built to hand software a decision rather than a paragraph. You pass it some state, meaning the text or data to be judged, plus a question whose answer space you declare in code, and it returns a value of that declared type together with a probability distribution across the possible answers.

The questions come in three shapes across the category. A choice picks one option from a closed set the caller supplies, such as which queue a support ticket belongs in. A score places the state on a bounded, declared scale, such as how severe a security incident is. A yes-or-no question (TypeSafe AI calls its version a Noul) comes back as a single probability between 0 and 1, such as whether an invoice needs human approval.

The strictest public definition, from DecisionEval, sets three conditions: the output space is closed and declared by the caller rather than baked into the weights, the model returns probability mass across every option rather than a bare pick, and that probability is calibrated well enough to threshold on. DecisionEval puts the last condition bluntly: "If the model says 0.9 on a hundred cases, roughly ninety of them had better be right, or every downstream automation rule you build on it is quietly wrong."

Worth knowing before you argue about edge cases: there is no standards body for this term. The glossary at systemonemodels.org says treating "decision model" as a description rather than a spec "avoids arguing about whether a given system qualifies." Loosely, the label covers encoder classifiers, span taggers, and anything wrapped in constrained decoding. Narrowly, it means the newer models trained from the start to produce a typed answer and a trustworthy number beside it.

How is a decision model different from asking a chat model for JSON?

A decision model differs from a chat model in JSON mode in three ways, and they are usually collapsed into one. The first is mechanical. Structured-output and function-calling modes constrain what a text model is allowed to write, but it still writes it. As Crescent AI puts the point, "Function calling and JSON mode constrain a standard autoregressive LLM's output to a schema, but the model still generates that output token by token." A string is produced, then parsed.

The second is that a parsed value carries no distribution. DecisionEval draws the line precisely: "An LLM with constrained decoding also produces a typed value. The distinction is that a decision model returns a distribution across the whole option set, and that the distribution is calibrated well enough to set a threshold on. Most constrained LLMs give you the option and a token probability, which is not the same thing." That matters because a distribution tells you whether the model was torn between two answers or had no idea, and those two failures want different fallbacks.

The third is that calibration is trained for, not hoped for. TypeSafe AI, which released the first commercial model of this shape on 15 September 2026, argues in its launch post that prompted confidence estimates from text models "tend to be overconfident and inconsistent," and that a model which can do a task 95% of the time but cannot say when it is in the 5% cannot automate that task.

The category's novelty is contested, though. Engineer Sean Goedecke, testing prefix-optimized single-token constrained classification on existing open-source models, reported a 2x to 3x speedup rather than the 40x to 200x TypeSafe publishes, and argued that fast parallel structured output over a small option set does not obviously require a new architecture.

Why does a decision model return a probability instead of just an answer?

A decision model returns a probability so that you can choose, in advance, which of its answers you are willing to act on without a human looking. The number is what turns one model into several different products.

The clearest published illustration comes from DecisionEval's measurement of TypeSafe's Jev on a frozen 2,000-decision test split. Accepting every answer gives 100% coverage at 0.740 accuracy. Accepting only answers at 0.7 confidence and above covers 57.6% of cases at 0.864 accuracy. Accepting only 0.9 and above covers 24.5% at 0.937 accuracy, with an expected calibration error of 0.045. DecisionEval's own gloss: "One model, three different products. Automate everything and accept a 26% error rate. Automate the confident quarter at 6% error and route the rest to a person. Which row you pick is a business question about your error budget, and the model cannot answer it for you." These are DecisionEval's figures on their own split, not independently reproduced.

This is also where the phrase "cannot hallucinate" needs care. When a decision model's output is constrained to schema-valid values, an off-schema value or a type error is structurally impossible, so the parse never fails and the model cannot invent an option you did not offer. That is a guarantee about format, not about correctness. DecisionEval states the limit plainly: a typed interface "does not remove the wrong answer. What it adds is that wrong answers arrive with a number attached."

When should you use a rule or a classifier instead of a decision model?

Use a plain rule when the decision is expressible as logic you can write down and test, and use a supervised classifier when the label set is stable and you already have labeled data. A decision model earns its place in between, where hand-written logic is too brittle and a training run per decision is too slow.

The rule-first argument is not new. Rule #1 of Google's Rules of Machine Learning is "Don't be afraid to launch a product without machine learning," with Rule #3 adding that you should choose machine learning over a complex heuristic, not over a simple one. If a regex, a lookup table, or a threshold on a field gets the decision right, it is cheaper, faster, auditable, and does not drift.

Against a classifier, the trade is flexibility for ownership. DecisionEval frames the difference well: "A classifier has a label set fixed at training time. A decision model takes the label set at call time. That is what lets one model serve forty different routing decisions across your product without forty training runs, and it is also why classifier benchmarks do not transfer." A traditional classifier, on the other hand, is fully owned and auditable, carries no per-call vendor cost beyond hosting, and has mature tooling around it, which Crescent AI notes suits teams with data science capacity and a stable, well-labeled task.

Known weaknesses matter too. TypeSafe documents failure modes for its current build that generalize to the category: unreliable counting and arithmetic, dates read as text rather than as ordered quantities, degraded accuracy when the state is large and full of irrelevant detail, and no text output at all. A decision model also needs a bounded, known answer space, and a probability about a person is a filter, not evidence.

What is the cascade pattern with decision models?

The cascade pattern runs a cheap decision model on every case, then escalates only the cases it is not confident about to a slower, more expensive frontier model. The decision model handles volume, the frontier model handles the hard minority, and the confidence threshold is the switch between them.

The pattern predates this category of model. FrugalGPT introduced the LLM cascade in 2023: run the cheap model first, check its work, escalate when the cheap answer looks unreliable. Later work, such as "Is Escalation Worth It? A Decision-Theoretic Characterization of LLM Cascades", characterizes the conditions under which deferring low-confidence queries to a stronger model actually pays off. What a calibrated decision model adds is a better switch, because the escalation trigger is a number the model was trained to get right rather than a proxy signal.

The economics are what make the pattern attractive. TypeSafe reports pricing of $0.042 per million input tokens with output unmetered, and end-to-end latency of 70 to 500 milliseconds, against $0.20 to $10 per million input tokens and multi-second responses for generative models. On its own four-workflow benchmark TypeSafe reports Jev at 67.8%, level with GPT-5.6 Terra and behind GPT-5.6 Sol at 74.1% and Claude Opus 5 at 73.1%, at roughly one two-hundredth of the cost. Every one of those figures is self-reported by TypeSafe and has not been independently reproduced, and the benchmark's "accuracy" means agreement with other models used as consensus labels rather than ground truth.

Vendor pages in this space claim most production stacks combine both kinds of model. That generalization is unsourced, so treat it as a vendor's description of its own customers rather than an industry measurement.

How does structured content improve decision model accuracy?

Structured content improves decision model accuracy by letting you pass only the material the question concerns, which keeps irrelevant detail out of the state. TypeSafe lists "large state full of irrelevant detail" as a documented weakness of its current build, using the term context rot for the effect, and its published state budget is 32,000 tokens, so what you leave out is as much a design decision as what you include.

This is where Sanity, the AI Content Operating System, is architecturally relevant to the term without being a decision model itself. Content in the Content Lake is stored as fields rather than as rendered pages, and a GROQ projection describes exactly which of those fields come back. The Sanity documentation describes the purpose as "stitching together a very specific response with only the exact fields you need," against the alternative of returning whole documents full of "actors, staff, posters, tag-lines, show-times, ratings, and whatnot" when three fields were the question. A query like *[_type == 'movie' && releaseYear >= 1979]{ _id, title, releaseYear } is the whole mechanism: the state you judge is the state you asked for.

Where the call itself runs is a separate question. Sanity Functions, which are small pieces of TypeScript or JavaScript that react to content events in the Content Lake, have a default timeout of 10 seconds and a maximum of 900, which comfortably contains a decision call in the 70 to 500 millisecond band TypeSafe reports. The relationship is that a typed decision is only as good as the state behind it, and structured content is how you control that state.

Last updated: October 6, 2026