Decision models, or when the answer is a probability

For most of the last few years we have thought about AI through one interface. A prompt goes in and text comes out. We ask a question and the model answers. We ask for code and it writes some. When we ask it to decide something, it turns the decision into words first.

Most production software does not need the words. It needs to know whether an operation is safe, which category a request belongs to, whether a customer should be handed to a person, whether a transaction looks wrong, whether an agent picked the right tool, whether a process should continue or stop. None of those answers has to be a paragraph. Sometimes the whole answer is approve = 0.97, or route = billing with a confidence of 0.92 beside it.

TypeSafe AI’s first model, Jev, is built on exactly that observation. It went into early access on 15 September 2026, and this note is about the idea behind it rather than a verdict on the product, which nobody outside the company is in a position to give yet.

A model that does not talk

Jev does not generate text. The company describes what it does as unstructured state in, typed probabilistic decisions out. You give it the current state of a program or a piece of natural-language context, you ask a question with a schema attached, and it returns a value inside that schema together with a probability. TypeSafe calls this class of model a System One Model, after Kahneman’s fast, intuitive mode of thinking, and says it was trained with a method it calls Reinforcement Learning for Calibrated Decisions.

The API has three primitives. Noul answers a yes-or-no proposition with the probability that it is true. Choice picks one of a declared set of options and returns the option, the distribution over all of them and a confidence. Score places the input on a scale you define and returns the score, its distribution and a confidence. Several questions can go in one call and are evaluated in parallel against the same state. The documentation’s own design rule is the telling part: instead of asking one broad question, ask each factor separately and combine the results with logic in your code.

That turns the model from a conversational partner into something closer to a function. Not a chatbot that happens to return JSON, but a callable that returns a typed value.

Why this is different from asking for JSON

Today, if I want a language model to route support tickets, I ask it to read the message and return one of billing, technical or sales as JSON. Then I parse the output, check it against a schema, and retry when it fails. Sometimes the model prefixes the JSON with an explanation. Sometimes it invents a field. Structured-output modes have made this much better, but underneath them there is still a generative model producing one token after another, and the structure is imposed on the generation afterwards.

Jev approaches the problem from the other side. Rather than constraining text after the fact, the model is designed not to produce text at all. The Register’s account of the launch gives the output for a routing question as a distribution, roughly {"billing": 0.08, "technical": 0.85, "sales": 0.07}, and nothing else. The company’s position is that if a piece of software only needs a decision among known options, there is no reason to generate a few hundred tokens of human language on the way to it.

What type safety buys, and what it does not

The company’s name is not an accident. In ordinary software, a function declared to return a boolean returns true or false. It does not return “I think this should probably be approved.” A decision declared as a choice among billing, technical and sales cannot produce a fourth category. Jev applies that contract to the model: what comes back is always inside the schema.

TypeSafe describes this as zero hallucinations, and the phrase needs the narrow reading the company itself gives it. In the launch post they write that the number is not empirical: schema matching is guaranteed, so they can put zero on the chart. That is a claim about format. It is not a claim about correctness. A response of fraud = false is perfectly well-formed and can still be wrong. The Register makes the same point: the model cannot fabricate a legal citation or a tool call, but returning structured responses with probabilities “does not preclude the possibility of being incorrect”. Armin Ronacher, quoted by TechCrunch, put it more bluntly: the model delegates the hallucination problem a little bit to the user.

I think that is fine, and I think it is the point. The interesting claim was never that the AI stops making mistakes. It is that the mistakes become something software can manage.

Confidence as part of the output

Every Jev decision comes with a probability. That small feature is what makes the rest of the design usable in production, because the application can now write its own risk policy.

The question stops being whether the AI is right or wrong and becomes what the system should do at this level of confidence. That is a question engineers know how to answer, and it can be answered differently for a refund of ten pounds and a refund of ten thousand.

Two cautions belong here. The first is that the training method behind the calibration is proprietary and new. The company says it optimises for what it calls epistemically honest probabilities, and nobody outside the company has yet published an independent calibration study. The second is that calibration is a property of a model on a distribution, not of a model in general. A probability that is honest on the vendor’s evaluation set is not automatically honest on your tickets. Arize, which builds evaluation tooling, made the same point while announcing its own benchmarks: validate the probabilities on representative data before you let them drive an action.

This is close to home for me. The QANTIS work is, at bottom, about whether a belief update can be trusted, and the answer we could give was a measured one: a posterior within a Hellinger distance of 0.0015 of exact Bayes, on stated hardware, under stated conditions. I would ask the same of any decision model before it gates anything that matters. Not “is it calibrated” but “here is the reliability diagram on our data, and here is where it stops holding”.

The numbers, and who produced them

The company’s own figures are these. End-to-end latency of 70 to 500 milliseconds. Between 40 and 200 times faster than frontier language models on what it calls System One shaped queries, because the decision outputs are computed in a single pass rather than token by token. A price of $0.042 per million input tokens, which the company prefers to write as $42 per billion, with output tokens free. The homepage headlines 193.6 times faster and 444.6 times cheaper on a set of workflow evaluations.

To the company’s credit, the launch post attaches the caveats itself: the workflows were made by individuals on its own model capabilities team, so some bias could exist, and they sit on the higher end of real-world gains. Those two sentences should travel with the headline numbers wherever they are quoted.

The early independent signals are narrower and more useful. TechCrunch reports that an engineer at Vercel, Pranit Sharma, replaced a general language model with Jev for classifying safety-related commands and saw results five to eighteen times faster with greater accuracy. Nikhil Mudholkar, the chief technology officer of Bryo AI, found Gemini slightly more accurate on a business-email classification test and Jev ten to twenty times cheaper, and singled out the probability that comes back with each answer as the reason it suited automation. Vercel added the model to its AI Gateway the day after launch. These are small tests by people with their own workloads, which is exactly the kind of evidence that eventually settles a question like this one.

A smart if-statement

The most useful way I have found to think about Jev is one the company uses itself: a smart if-statement.

Ordinary software is powerful because it is deterministic.

if amount > 10000:
    review()

The world is not always that clean. “Does this transaction look suspicious?” is very hard to express as a handful of conditions, and a language model answers it too freely. The middle ground looks like this.

risk = decide(transaction)   # a calibrated probability, not a paragraph

if risk > 0.95:
    block()
elif risk > 0.70:
    human_review()
else:
    proceed()

The intelligence is not the application. It is a primitive the application calls, with a type and a probability, and the control flow around it is ordinary code that can be read, tested and audited.

Small decisions instead of one large agent

This is where the idea meets the harness engineering argument from my previous note. Many agent systems today give one model a great deal of responsibility. It plans, chooses tools, interprets policy and judges whether its own result is good. A mistake anywhere in that chain propagates to the end.

The alternative is to decompose. An incoming request passes through a sequence of narrow questions: what is the intent, how risky is it, is it permitted, is the confidence high enough. Each question is a single typed decision. The logic between the questions is code. TypeSafe’s documentation argues for this pattern directly, and its workflow evaluations are built as compute graphs of small Choice, Score and Noul decisions rather than as one long prompt. The architectural shift is that the model no longer owns the reasoning as a whole. The software owns its structure, and the model fills in the judgements.

Three kinds of intelligence in one workflow

The most likely misreading of Jev is that it makes language models unnecessary. It does not, and it is not designed to. Writing a research report, generating code, designing a solution, answering a long and ambiguous customer message, investigating an ill-defined problem: these remain the territory of generative models. What changes is that a workflow can now use more than one kind of intelligence.

1. 01 Generative model generate, reason, plan
2. 02 Decision model classify, score, verify, gate
3. 03 Code enforce, execute, persist

The pattern is especially interesting for agents. An agent can reason its way to “I should drop this production table.” Before anything executes, a separate decision model can be asked a single question about that action and return safe_to_run = 0.03. The harness then does what code does: below a threshold, require a person. TechCrunch reports that TypeSafe’s founder already sees users deploying the model to track agent traces and catch jailbreaks, as a check on misbehaviour that sits beside the agent rather than inside it. That is the verification and permissions layer of the harness argument, made concrete with a second model that cannot answer in prose.

It is also how the systems I work on are shaped. NowFlow treats an approval gate as a routing step, and a calibrated probability is a natural input to such a gate. NODERIQ exists to carry the evidence for a recommendation to the point where a person decides. And the reason the planner stays classical in the QANTIS work is the same reason the threshold here lives in code: whatever produces the probability, the authority to act should sit somewhere deterministic and inspectable.

What is not known yet

Jev is five days old as I write this. It is in early access behind a waitlist. The company spent roughly two years in stealth and announced a $40 million seed round led by DCVC alongside the launch; its founder, Diogo Almeida, worked at OpenAI on the instruction-following research behind ChatGPT. None of that tells us how the model scales, how calibration holds across domains, what happens on inputs far from the training distribution, how stable the accuracy is on real production decisions, or whether the advantage survives the next generation of general models. Calling it a replacement for language models would be premature, and the company does not call it that either.

From prompts to decision infrastructure

The idea underneath the product is worth taking seriously regardless of how the product fares. Not every intelligence problem is a text-generation problem. Sometimes what we want from AI is a decision, a score, a probability, a gate, a route or a verification, and if those small decisions become fast, cheap and reliable enough, a large share of AI’s economic effect will happen not in chat windows but inside billions of software decisions that no user ever sees.

The stages of the last few years point the same way.

1. Prompt engineering
2. Agent engineering
3. Harness engineering
4. Decision models

If the direction holds, the basic unit of an AI application may not be a conversation at all. It may be a loop that a user never sees.

1. State
2. Decision
3. Probability
4. Policy
5. Action
6. Evidence

And if that happens, the most important output of an AI system will not always be words. Sometimes it will be a small decision, made reliably, with a number beside it that says how much to trust it.

Sources

1. Introducing System One Models and Jev (TypeSafe AI, 15 September 2026) typesafe.ai
2. TypeSafe API documentation: Choice, Score and Noul docs.typesafe.ai
3. TypeSafe AI emerges from stealth with $40M in funding (Business Wire, 15 September 2026) morningstar.com
4. TypeSafe AI debuts model for machines that plays Doom (Thomas Claburn, The Register, 16 September 2026) theregister.com
5. A new kind of AI model from a ChatGPT inventor is thrilling developers (Tim Fernholz, TechCrunch, 18 September 2026) techcrunch.com
6. TypeSafe Jev: can decision models replace LLM judges? (Arize AI, September 2026) arize.com