What Is a Decision Model? Jev, Laya, and Typed Answers Instead of Parsed Prose

Quick answer
A decision model answers a closed question with a typed value and a probability, not generated text.
You send a state plus questions; each question is a choice from declared options, a score on a rubric, or a yes/no probability.
The answer is already machine-readable, so there is no JSON repair, no prose parsing, and no retry loop for malformed output.
“Cannot hallucinate” means it cannot return an option you did not declare. It can still choose the wrong declared option.
Use one for routing, triage, guardrails, reranking, and verification. Keep generation, arithmetic, permissions, and side effects in an LLM or ordinary code.

What is a decision model?

A decision model is a machine-learning model that returns a bounded answer to a question your code defined in advance. It takes a state, which can be a support ticket, a chat message, a JSON record, or a document, and a set of questions over that state. Each question is one of three shapes: a choice from a list, a score on an ordered rubric, or a yes/no proposition. The model returns the selected option, a probability for every option, and a confidence value, all in a schema your code already knows how to read.

This is a narrower contract than a chat model. A language model generates a sequence of tokens, and even when you ask for JSON, the output is text that has to be parsed and checked. A decision model scores the options you supplied and returns one of them. There is no prose to parse and no invented field. The trade is flexibility: it cannot explain itself, write a summary, or answer a question you did not ask.

How is it different from an LLM or a classifier?

A classifier also returns a label, but the label set is usually fixed at training time and the model is trained for one task. A decision model is designed to be given a new question and a new option set at request time, so the same endpoint can triage a ticket, judge whether a tool call is destructive, and rank a search result. Whether it is accurate on your new option set is a separate question, and one you have to measure rather than assume.

An LLM is still the right tool when the output is language: an explanation, a draft, a plan, a code change, or a conversation. A decision model is the right tool when the output is a branch. The practical pattern is to use the decision model for the branch and the LLM only for the branch that actually needs language. That keeps the cheap, fast, typed judgment in front and the expensive generation behind it.

A decision model request, in the shape Jev, Laya, and Clef share:

  state      = "I was charged twice for March. Refund the duplicate or I cancel."
  questions  = {
    department : choice  { billing | technical | sales }
    urgency    : score   [ low | normal | high | critical ]
    churn_risk : noul    "Does the writer threaten to cancel?"
  }

  response   = {
    department : { choice: "billing", probabilities: {...}, confidence: 0.93 }
    urgency    : { score: 2.4, probabilities: {...}, confidence: 0.71 }
    churn_risk : { noul: 0.97 }
  }

Why do probability and confidence matter?

A decision model returns a distribution over your options, and a confidence value derived from that distribution. The distribution is useful because it tells you how close the call was: 0.51 versus 0.49 is a coin flip, while 0.97 versus 0.02 is not. The confidence value is useful because it gives your code a single number to threshold. Neither is a guarantee that the answer is correct, and neither should be treated as one.

Calibration is the property that makes the numbers worth using. A calibrated model that says 0.9 on many inputs should be right about ninety percent of the time. Vendors train for this explicitly, but calibration is measured on a distribution of inputs, so it can drift when your inputs change. The practical move is to set a threshold, send everything below it to a human or a stronger model, and measure how often the high-confidence answers are actually right on your own data.

Where does a decision model fit in an app?

Put deterministic code first and the model second. Hard rules for permissions, blocked data classes, rate limits, amounts, and allowed destinations belong in code, because they must not depend on a probabilistic judgment. The decision model handles the part that is genuinely semantic: what kind of request is this, is it urgent, does it contain a refund demand, is this tool call consistent with the stated plan. Then your code maps the answer to an action, and that action still has its own validation.

The common production shapes are routing, triage, moderation, retrieval reranking, extraction validation, and agent guardrails. In each one the model is making a judgment your software needs thousands of times, where a wrong answer is survivable because the next layer catches it. That last condition is the design constraint. If a wrong branch is unrecoverable, the model should not be the only thing standing between the request and the action.

When should you not use a decision model?

Do not use one when the output has to be text. It cannot write the reply, summarize the document, explain the decision, or produce the code. Do not use one for arithmetic, date math, or counting either; these are deterministic operations that belong in code, and the model is weaker at them than the language runtime you already have. Multi-hop reasoning and tasks with indirect references are also a poor fit, because the model evaluates the state you supply rather than searching for more.

Low-volume, high-stakes decisions are another bad fit. If you make ten decisions a day and one wrong answer is expensive, a frontier LLM with a careful prompt and a human review is usually the better trade. The decision model’s advantage is volume: it is cheap and fast enough to judge every request, every tool call, or every row. At low volume, that advantage is worth little and the evaluation burden is the same.

What should you check before adopting one?

Check hosting and data handling first: whether the model runs behind an API, on your machine, or inside your cloud, and whether the vendor retains or trains on your inputs. Then check the interface: which question types it supports, how large a state it accepts, whether it handles images, and which languages it was trained on. A model that is excellent in English benchmarks may be untested on the language your users actually write.

Finally, check the operational facts: price per million input tokens, latency at the percentile you care about, rate limits, versioning, and whether you can fine-tune or self-host. Those are the constraints that decide whether the model fits your app, and they matter more than a headline benchmark score. Benchmark suites are useful for narrowing the field, not for choosing the winner.

Where this bites vibecoders
The pattern an AI assistant reaches for is an LLM call for every branch: classify this ticket with a prompt, ask for JSON, parse it, retry when the JSON is malformed, and hope the label is one you expected. It works in a demo and becomes a pile of parsing and fallback code in production. A decision model removes that layer, but it does not remove the need to check the answer. The useful habit is to write the branch as a typed question, gate on confidence, and keep the action in ordinary code.

Where AI coding assistants get this wrong

Using a decision model for open-ended generation, then treating the missing answer as a bug.
Asking one compound question (“Is this urgent and which team handles it?”) instead of separate atomic questions.
Trusting a high-confidence answer as authorization for an irreversible action.
Skipping calibration and assuming a confidence of 0.9 means a 90% chance of being right on the new data.
Choosing a provider from a vendor benchmark instead of testing on the inputs the app actually receives.
Hard-coding provider-specific response fields throughout the app, making a later swap a rewrite.

Checklist

Name the exact branch the model will decide.
Write each question as one atomic choice, score, or yes/no proposition.
Define the option descriptions so a new label is unambiguous.
Decide what happens below the confidence threshold before shipping.
Keep permissions, limits, and side effects in deterministic code.
Test on 100-300 labeled inputs from your own traffic.
Wrap the provider behind an interface so it can be replaced.

FAQ

Is a decision model just a classifier?

It is classifier-shaped, but the important difference is the request-time interface. A traditional classifier is trained for a fixed label set and usually deployed for one task. A decision model accepts the options and rubric in the request, so one endpoint can answer different questions. Accuracy on a new option set still has to be evaluated, and that is the work a classifier would have moved into training.

Can a decision model hallucinate?

It cannot return a value outside the schema you supplied, which is what vendors mean when they advertise zero hallucination. It can return a wrong but valid option, and that is the failure mode that matters. The defense is the same as any classifier: a labeled test set, a confidence threshold, a fallback path, and monitoring after release.

Do I still need an LLM if I use one?

Usually yes. The decision model handles the branch, and the LLM handles the language: the reply to the customer, the explanation for the reviewer, the code change, or the summary. Using a decision model to replace an LLM entirely only works when every output the app needs is already a closed choice, score, or yes/no answer.

How accurate does it need to be?

That depends on the cost of each kind of error, not on a universal number. A triage model that routes to a human on low confidence can tolerate more mistakes than one that issues refunds. Define the acceptance criteria before testing: the minimum accuracy on the held-out set, the maximum share of low-confidence answers, and the latency and cost budgets.

What is the difference between choice, score, and noul?

Choice picks one option from an unordered set, such as a department. Score places the state on an ordered rubric and returns a probability-weighted position, such as severity. Noul returns the probability that a yes/no statement is true. Jev and Laya share those three text primitives; Jev also has a preview Box type for image localization. OpenAI’s Decisions API calls the yes/no type a predicate.