Decision Models: A New Branch Beside Generative LLMs

For the past few years, the most common way to “add AI” to a piece of software has been to call a Large Language Model. Need to classify a ticket? Call an LLM. Need to know whether an email is phishing? Call an LLM. Need to rate the urgency of an incident? Call an LLM again, and tell it to “return JSON only”.

Look closely at those places, though, and the software does not need a paragraph. It needs a decision: which team gets this ticket, should this transaction be blocked, does a person need to look at it. The text is just a wrapper we force the model to write, so that our code can peel it off again.

This series is about an emerging approach that drops the wrapper: the decision model — a model that does not generate strings, but takes the program’s state plus questions with a pre-declared answer space, and returns typed decisions with a probability distribution. The clearest representative today is JEV from TypeSafe AI, launched on September 15, 2026.

This opening post answers four questions: what a decision model is, how it differs from text-generating LLMs and structured output, what JEV has actually published, and where a decision model belongs in a real system. The internals — the three question types, the parallel sampler, RLCD, calibration — are saved for part 2.

01A decision wrapped in text

Take a very familiar example: a customer support system receives the message

“I was charged twice. Please fix this ASAP.”

and has to do two things: send the ticket to the right team (billing, technical or other), and decide whether it needs urgent escalation.

The familiar LLM approach

The usual approach is a prompt along the lines of: “Read the following message, tell me whether it belongs to billing / technical / other and whether it is urgent. Answer in JSON with two fields, department and urgent.” The model returns a string. Code parses that string, checks that the fields are present and the values are in the list, and only then runs the if/else.

This works — plenty of production systems run exactly like this. But it brings four quite specific pain points.

Format drift. The model may return "Billing" instead of "billing", add a sentence of explanation before the JSON block, invent a "payments" team that is not on the list, or drop a field. The code needs a parse, validate and retry layer for every one of those cases.

Latency. An LLM generates one token at a time, each token depending on the previous ones. Even when all we need is a single label, the model still has to walk through every token of the JSON block, and often “thinks” before that if it is a reasoning model. When the call sits inside a loop or a dependency chain, latency adds up fast.

Cost. Output tokens usually cost several times more than input tokens. Paying for brackets, field names and explanations that the code will throw away is hard to justify once calls reach the millions.

Unusable confidence. This is the most important pain point, and the least discussed. To automate something, we need to know when the model is not sure: run the confident cases automatically, route the ambiguous ones to a person. We can ask the LLM to “include a confidence between 0 and 1”, but that number is a string the model writes, not a measured probability. TypeSafe puts it neatly in its launch post: if a model can do a task 95% of the time but cannot tell you when it is in the other 5%, that task cannot be automated.

The problem is not intelligence

Notice that none of these pain points is about the model “not being smart enough”. A strong LLM will almost certainly file “charged twice” under billing. The problem is the interface: we are using a model optimized to write text for humans, and forcing it to act as a function that returns values for programs.

Put differently, the decision layer of a piece of software needs three things: typed output that code can use directly, trustworthy probabilities to set thresholds on, and enough speed and low cost to appear in many small branches of a program. It does not need good prose.

That is exactly the gap decision models aim at.

02What a decision model is

The easiest way to picture a decision model is to compare its interface with an LLM’s. The author’s source notes for this series use exactly this comparison:

LLM            : text / context            ->  an arbitrary string
Decision model : state + typed questions   ->  typed probabilistic decisions

TypeSafe describes JEV in almost the same words: “a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out”.

The definition used in this series

In this series, a decision model is a model that:

1. takes a state — the content to evaluate, which can be text, a JSON object or an array;
2. together with one or more typed questions, each with an answer space declared before the model is called;
3. and returns, for each question, a typed value inside that space, together with a probability distribution over the answers.

The key phrase is “declared before”. With an LLM, the model decides what to write; we can only instruct and hope. With a decision model, the application itself defines the answer space, and the model can only distribute probability over it.

Three question types

JEV defines three question types. This post only names them so we share a vocabulary; how each one works and how to read its output is the subject of part 2.

• Choice — pick one of a set of known options. Good for routing, intent classification, tool selection.
• Score — place the case on an ordered scale. Good for urgency, risk, relevance.
• Noul — a yes/no question, but the output is not true/false; it is the probability of “yes”. Good for guardrails, approval gates, spam signals.

The ticket example, rewritten for a decision model

The example from section 1 becomes one request with a state and two questions — a Choice and a Noul:

{
  "model": "jev-latest",
  "state": {
    "message": "I was charged twice. Please fix this ASAP."
  },
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "billing": "Payment, invoice or refund problem",
        "technical": "Bug or product failure",
        "other": "None of the above"
      }
    },
    "urgent": {
      "type": "noul",
      "instructions": "Does this require urgent escalation?"
    }
  }
}

And the response looks like this:

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "billing",
      "confidence": 0.95,
      "probabilities": { "billing": 0.95, "technical": 0.03, "other": 0.02 }
    },
    "urgent": {
      "type": "noul",
      "noul": 0.82
    }
  },
  "usage": { "input_tokens": 120, "output_tokens": 12 }
}

A few things are worth noticing in this example.

First, the answer for department cannot be "payments" or "Billing". The answer space is the three keys billing, technical and other — the model can only distribute probability over exactly those three.

Second, there is nothing to parse. answers.department.choice is already a value in the program’s enum.

Third, and most important, every answer comes with a number that code can put a threshold on: confidence and probabilities for a Choice, noul for a yes/no question. Routing a ticket to billing at confidence 0.95 is a very different decision from doing it at 0.55.

Figure 1 at the top of the post puts the two approaches side by side. The top row is the familiar LLM path: prompt, sequential token generation, a text or JSON string, parse and validate, and only then an if/else branch. The bottom row is the decision-model path: one request with state and questions, the model answers in parallel, the output is already schema-true, and policy code reads the confidence and branches.

03How it differs from text LLMs and JSON mode

The first objection is usually: “But LLMs already have JSON mode and structured output.” True, and this is where we need to separate things carefully.

What structured output does solve

First-generation JSON mode only guaranteed that the output was valid JSON. Later structured output went further: some providers use constrained decoding to guarantee that output always matches the JSON Schema we supply. OpenAI’s Structured Outputs documentation, for example, describes it as ensuring the model “will always generate responses that adhere to your supplied JSON Schema”.

So the format drift pain point on its own is handled quite well by structured output on APIs that support it. If the only difference between a decision model and an LLM were “schema-correct output”, it would not deserve a series.

What structured output does not solve

What structured output does not change lives at a deeper level:

• Generation is still sequential. Constrained decoding only restricts which tokens are allowed at each step; the model still produces one token at a time. Latency and cost still grow with output length.
• The optimization target is still text. The model was trained to write strings that humans prefer (RLHF) or verifiable solutions (RLVR). Filling in a JSON template correctly is something we impose from the outside, not something it was optimized to do.
• Probability is not a first-class output. To get a confidence, we either make the model write a number itself or compute one from token logprobs (when the API exposes them). Neither is something the model was trained to get right. TypeSafe observes that even when prompted for a confidence estimate, LLMs tend to be overconfident and inconsistent.

Side-by-side comparison

Putting it together, based on the comparison table in TypeSafe’s launch post and the author’s source notes:

The last row is not a footnote. TypeSafe’s documentation on the weak spots of jev-1.13 says it plainly: “jev-1.13 is not trained to generate text”, and the advice for text generation is “Use a generative model”. A decision model is not a better LLM — it is a different tool that gives up writing entirely in exchange for the rows above.

That is also why the series says a new branch beside LLMs rather than a new branch of LLMs. TypeSafe calls JEV “a new class of frontier models” built on “a new model architecture”, and the launch post’s FAQ says outright that “Jev is neither small nor an LLM”. What it has not published is what JEV is built from or whether it is a transformer inside. Calling it a kind of LLM would contradict TypeSafe’s own description.

Type safety is not correctness

One phrase in TypeSafe’s launch post is very easy to misread: JEV “can’t hallucinate”, and “the model never makes type errors”.

The second half is true in a strict sense: because the answer space is defined in advance, the model cannot return a value outside it. TypeSafe calls finding a counter-example “mathematically impossible”, and in its hallucination-rate chart it notes that its own 0% figure “is not empirical” — it comes from guaranteed schema matching, not from measurement.

But go back to the ticket example. Suppose the message is “The app crashed right after I paid, and now I see two charges”. Is that billing or technical? A decision model might return technical with confidence 0.7. That answer is well-typed — it is one of the three valid keys — and it can still be wrong as far as the business is concerned.

well-typed  !=  true

The safe production reading, following the author’s source notes: “can’t hallucinate” should be read narrowly as never answering outside the schema, not as “always right about the world”. Type safety removes one class of errors — errors in the shape of the output. Calibrated probabilities help you manage the remaining class — picking a valid but wrong answer — by telling you when to be suspicious. They do not remove it.

Part 2 goes deeper here: what calibration means, why it is a property of a set of predictions rather than of any single answer, and how to pick thresholds on your own traffic.

04JEV, the first representative

On September 15, 2026, TypeSafe AI announced System One models — “a new class of frontier models built to make fast, structured decisions that software can use directly” — and the first public model in that class, JEV, released in early access. The launch post was written by Diogo Almeida, TypeSafe’s founder. In it, the author recounts having previously helped build the methods at OpenAI that made language models good at following instructions, and says the driving question behind the work was: models have been superhuman at chat for years, so where is all the automation?

Why JEV as the representative

The series picks JEV for four reasons:

• It is the first commercial model clearly positioned in this class. Not a classification head bolted onto an LLM or a prompt library, but a model designed, trained and sold specifically for typed decision-making.
• It has a public API and SDKs. Every model is served through the POST /v1/systemone endpoint, and there are official SDKs for Python and JavaScript. Claims about the interface can therefore be checked against source code, not just marketing copy.
• It documents its weak spots per version. TypeSafe maintains a “model jaggedness” page listing where jev-1.13 performs poorly — a rare practice and a very useful one when designing systems.
• It already has an ecosystem. Besides the official SDKs, TypeSafe ships an adapter that puts LLMs behind the same interface, and the community already has projects imitating JEV’s interface. Part 3 covers this.

Two big caveats come with that: JEV is a closed model — there are no public weights — and all benchmark numbers are published by the vendor itself.

What TypeSafe has published

The points below come straight from TypeSafe’s launch post and model documentation:

• A three-part stack: “a new model architecture, parallel sampler for maximum efficiency, and training method we call Reinforcement Learning for Calibrated Decisions (RLCD)”. Part 2 explains each one as far as the public documentation allows.
• Up to 255 options per Choice: “Jev supports a cardinality up to 255”. For larger sets, the vendor’s Wikiracing demo uses two stages: score independently to narrow down first, then make an explicit Choice.
• Latency: end-to-end response time of “70ms-500ms”, compared with “3 to 329 seconds” for frontier models by the vendor’s measurement; the vendor says this can be roughly 40–200× faster “for System One shaped queries”.
• Pricing: $0.042 per million input tokens ($42 per billion), and output tokens “FREE (too cheap to meter)”. For comparison, the vendor cites LLM input prices from $0.20 to $10 per million tokens, with output tokens about 5× more expensive than input.
• Current version: the models page lists jev-1.13.0, a 64k-token context per request, and text-only input (a string, JSON object or array). The jev-latest alias points to the newest stable release; the vendor recommends pinning a specific version ID if you have tuned confidence thresholds against it.

The 193.6× and 444.6× benchmark — read with the vendor’s own caveats

The most eye-catching number on TypeSafe’s homepage is that JEV is 193.6× faster and 444.6× cheaper. To its credit, the launch post itself lists a fairly complete set of caveats for this number:

• The numbers come from workflow evals the vendor built itself; the vendor says they “are on the higher end of real world gains”.
• The workflows were not chosen to make JEV look good and are not in the training distribution, but they were made by people on the vendor’s model capabilities team, so “some bias could exist”.
• There are no ground-truth labels: the reference answer is the average of GPT-6 Astra and Fable 5.1, which the vendor says biases answers toward OpenAI’s and Anthropic’s models.
• The LLMs in the comparison run through the vendor’s “System One LLM” wrapper so they return decisions in the same format — the vendor says this is the most accurate way to get decisions from LLMs, but also slower and more expensive than having the LLMs return decisions without probabilities.
• The evals are generally run from the team’s laptops on the West Coast, where the service is currently based.

A reasonable reading: this is evidence that specialization can bring very large gains on exactly the kind of task it targets — narrow questions with a declared answer space, inside a software workflow. It is not evidence that JEV is “smarter than LLMs” in general, and it does not replace measuring on your own workload.

Why “System One” and “Jev”

The FAQ at the end of the launch post explains both names. System One is inspired by Daniel Kahneman’s Thinking, Fast and Slow and its distinction between System 1 — fast, intuitive thinking — and System 2 — slow, deliberate reasoning. Jev is named after William Stanley Jevons: the vendor expects machine intelligence to follow the same path as coal after the steam engine became more efficient — lower cost drove more demand, and every order-of-magnitude drop in the cost of intelligence unlocks orders of magnitude more use cases.

The vendor also acknowledges that “System 1” has connotations of being error-prone, and says it will explain later why it believes System One models can be made more reliable than the alternatives.

The blog’s reading: treat the name as a metaphor for a product class — a model focused on fast, local, bounded judgments — not as a claim that JEV has “a human-like System 1 brain”. The metaphor also hints at the division of labor in the next section: the decision model for fast judgments, the LLM for slow, open-ended reasoning.

What has not been published

To keep the line between fact and speculation clear, here is what is not in TypeSafe’s public documentation today:

• parameter count, number of layers, attention design, and whether the backbone is a transformer at all;
• how the parallel sampler is actually implemented;
• the specific loss and reward of RLCD, and how calibration labels are produced;
• training data and compute;
• weights for self-hosting.

So this series will not claim that JEV is “really a classification head on top of an LLM”, “an encoder-only transformer” or “an LLM with the decoder removed” — unless TypeSafe publishes that. Open-source projects that imitate JEV’s interface do not prove that JEV’s internals look like theirs either.

05Where a decision model fits in a system

If a decision model cannot write text, and an LLM is slow and gives no trustworthy probabilities, the practical question is: in a real system, who does what?

Figure 2 splits the system into four roles. Each role keeps the part of the work where it has the advantage.

Code keeps the deterministic part

Anything that can be written as an exact rule belongs in code: arithmetic, counting, date and time comparison, permission checks, exact ID matching, and every side effect such as issuing a refund or freezing a card. This is not generic advice: the jev-1.13 weak-spot list says “Jev is not a calculator”, recommends keeping arithmetic in code, and notes that the model reads dates as text rather than as ordered quantities.

Code also does the preprocessing: trimming the state down to what the question needs. TypeSafe’s documentation notes that accuracy falls as the state grows with content unrelated to the decision.

The decision model keeps bounded fuzzy judgments

The decision model answers questions that hand-written if/else cannot handle but whose answer space is already clear: what is the customer’s main intent, does this message show signs of fraud, how frustrated is the customer, is this passage relevant to the question.

The author’s source notes and TypeSafe’s launch post point to the same principle: decompose the questions. Instead of asking “how should this case be handled?”, ask about each signal separately — intent, fraud, urgency — and let code combine them. Business rules stay in code; the model only supplies semantic signals.

Policy code reads the probabilities

This is where probabilities become valuable. Instead of one threshold for everything, policy sets thresholds by the stakes of the action. Recommending an article to a customer is harmless if wrong, so it can be automated at moderate confidence. A refund needs a much higher threshold, or always a human in the loop. The exact numbers have to be chosen from real traffic and the cost of each kind of mistake — part 2 covers this in detail.

The LLM keeps writing and open-ended reasoning

When the decision is “we need to reply to the customer by email”, “we need to summarize the case history” or “we need a multi-step plan”, that is a job for an LLM. A decision model can also sit in front of the LLM to decide whether to call it at all, and behind it to score or check its output — TypeSafe’s launch post lists “Score, judge, verify, guardrail” of LLM outputs as a use case.

People keep the hard cases

High-stakes or low-confidence cases go to a human reviewer. That is not a weakness of the design; it is the point of it. Because the decision model returns probabilities, the system knows which cases need a person, instead of sending everything to people or nothing at all.

Back to the ticket example

For the message “I was charged twice. Please fix this ASAP.”, the hybrid flow could look like this:

1. Code takes the message and a few necessary account fields; it does not send the entire transaction history.
2. The decision model answers department (Choice) and urgent (Noul).
3. Policy: if department is billing with high confidence, route directly; if urgent crosses its threshold, flag the ticket as priority.
4. If a reply to the customer needs drafting, call an LLM to write it.
5. If the confidence for department is low, or the next action is a refund, hand it to a person.

No step needs to parse text to extract a decision. And at every branch, the system has a number that explains why it went that way.

06Summary

A decision model is not a better LLM. It is a different answer to the question “how does software make use of AI”: instead of letting the model write a string and hoping the program understands it, define the decision space up front and let the model return probabilities that code can use directly.

What to take away:

• most places we wire an LLM into software only need a decision — route, gate, score, escalate — not a paragraph;
• a decision model takes a state plus questions with a pre-declared answer space, and returns typed decisions with a probability distribution;
• structured output fixes schema drift for LLMs, but does not change sequential generation and does not make probability a first-class output;
• well-typed does not mean correct — type safety removes one class of errors, calibration helps manage the rest, it does not remove it;
• TypeSafe AI’s JEV is the first representative with a public API, SDKs and documented weak spots, but it is a closed model and its benchmarks are vendor-published, with the caveats the vendor itself lists;
• “decision model” is this blog’s term; TypeSafe calls the class System One models, after Kahneman’s System 1 / System 2;
• in a real system, code keeps the deterministic part, the decision model keeps bounded fuzzy judgments, the LLM keeps writing and open-ended reasoning, and people keep the hard cases.

The next post in the series opens up JEV as far as the public documentation allows: the full request/response loop, the three question types Choice, Score and Noul and how to read each one’s output, what the parallel sampler and RLCD are, what calibration means in practice, the jev-1.13 weak-spot list, and a dedicated section on what TypeSafe has not published. After that, part 3 surveys the ecosystem around JEV, and part 4 applies decision models to a concrete problem: designing a Chrome extension for web data extraction.

References

• TypeSafe AI — Introducing System One Models & Jev, September 15, 2026 (launch post, comparison with LLMs, workflow evals and caveats, FAQ on the names)
• TypeSafe AI — Models (version jev-1.13.0, pricing, context, jev-latest alias)
• TypeSafe AI — Jev 1.13 jaggedness (jev-1.13 weak spots, including Generation)
• TypeSafe AI — typesafe-sdk-python and its request/response schema
• TypeSafe AI — API reference
• TypeSafe AI — Workflow evals
• TypeSafe AI — system-one-adapter-python
• OpenAI — Structured Outputs
• Daniel Kahneman — Thinking, Fast and Slow, 2011
• Author’s source notes: “JEV Deep Dive — How the System One model works” (Notion, September 30, 2026)