Decision models (1): you don't need a thousand words to decide

For three years, we have grown used to associating artificial intelligence with text generation. You ask a model a question, it thinks, it produces a few dozen or a few hundred words. A human reads the answer, or a program picks up the result and tries to do something with it.

This way of working makes perfect sense for drafting a letter, summarizing a consultation, or writing code. It makes much less sense when all you want is to make a decision. And a good part of what we automate for our clients comes down to a decision: does this email go to the front desk or to accounting, is this file complete, is this patient message urgent.

On September 15, 2026, a San Francisco company, TypeSafe AI, unveiled a model that does exactly that. It is called Jev, and it cannot write a sentence. This first part explains what this model changes compared to a generative model, what has been verified and what has not been yet, and why the same capability already existed, in part, in the open models that anyone can run on their own machine. The second part looks at what happens to automation when a decision costs a hundred milliseconds instead of ten seconds.

What a generative model actually does when asked for a decision

Take an everyday example. A customer writes: “I received my order, but the product is broken.” We want to know which department to send the message to, with what priority, and whether a refund is possible.

The common practice is to ask a large language model to answer in a structured format the program can read. The model then writes out, as text, the equivalent of this small table:

It’s worth looking at how this result is produced. A language model writes in small chunks of text called tokens: a word, part of a word, a brace, a quotation mark. Each token is chosen based on all the previous ones, one after another. The answer above is about thirty tokens long, so about thirty successive passes through the model. The “structured output” mode offered by providers does not change this mechanism: at each step it forbids tokens that would break the format, but the answer is still written token by token.

Our program then waits for the text to finish, checks that it is well formed, extracts the fields from it, and then applies its own rule. The full path looks like this:

This detour costs time, a few seconds per call, and it opens the door to formatting errors that the program then has to catch.

A model that cannot write

Jev removes this detour. The program sends it a state, meaning a description of the situation in free text or data, and one or more questions whose possible answers are fixed in advance. TypeSafe offers three types of questions: a choice among named options, a rating on a scale described by levels, and a yes-or-no answer. For each question, the model returns a typed value and a probability for each option. Here, simplified, is the kind of response TypeSafe documents:

There is no more text to interpret. The possible outputs were defined before the call, and the program receives numbers it knows how to compare against a threshold. All the questions asked about the same state are evaluated together, in a single pass, rather than one after another.

Placed side by side, the two paths come down to this:

This is the point worth emphasizing, because everything else follows from it. Until now, the decision was a byproduct of generation: the model was made to write, and then its decision was read out of the text. Jev reverses the relationship.

TypeSafe calls Jev a “System One Model.” The term refers to the two systems of thinking described by psychologist Daniel Kahneman: system 1, fast and intuitive, which recognizes a face or senses that a message is aggressive without thinking it through, and system 2, slow and deliberate, which works out a multiplication or weighs an argument. The reasoning models that emerged in 2024 and 2025, the ones that “think” before answering, were presented as artificial system 2s. TypeSafe moves in the opposite direction and claims a system 1: an immediate judgment, with no written reasoning, sold as a product in its own right.

TypeSafe draws a strong claim from this, which its announcement puts as follows.

A language model is said to hallucinate when it confidently writes something false or made up. Strictly speaking, the claim holds: a model that writes nothing cannot invent an option, a field, or a fact, and its answer always stays among the choices it was given. That does not mean the choice is correct. Jev can still pick the wrong option with high confidence, which is why the quality of the probabilities it returns matters so much.

The company describes a training method it calls Reinforcement Learning for Calibrated Decisions. The stated goal is not for the answer to please a human reviewer, as in the training of conversational assistants, but for the returned probability to match the actual frequency of correct answers: when the model says 0.8, it should be right eight times out of ten. TypeSafe reports response times between 70 and 500 milliseconds depending on load, an example workflow completed in 114 milliseconds versus 8.6 seconds for the same chain handled by a large language model, and a price of $0.042 per million input tokens.

These figures call for three reservations, which we take from the first analyses published in the week of the launch. First, they come from TypeSafe: the speed and cost comparisons use as a baseline models that write out a full chain of reasoning, and the gap narrows considerably against the closest model in accuracy. Second, the internal test set is graded by other language models, not by human reviewers, and no calibration curve has been published to date: the documentation refers the user back to their own measurements. Finally, Jev is a closed service, and neither its architecture nor its size is known. Some commentators see it as a carefully trained classifier rather than a breakthrough. That debate does not take anything away from what interests us here, which is the change in interface, and it justifies looking at what open models already allow.

SemIf: the same capability, read out of an open model

The very next day after the announcement, on September 16, an independent developer, Theodore Lee, published a project first named OpenJev, then SemIf, with no connection to TypeSafe. The project does not try to reproduce the model, none of which is public, but rather the interface: a situation, options, probabilities.

SemIf relies on Qwen3.5-4B, an open model with four billion parameters that fits on a consumer graphics card. It does not ask the model to write. It presents it with the situation, the question, and the options labeled A, B, C, and it reads directly the scores the model assigns to each of those letters for the next token. These internal scores, called logits, exist at every step in any language model: they are the numbers from which the next token is normally drawn. SemIf converts them into probabilities and stops there. No token is generated.

The author calls this a semantic if: a software condition whose rule is not written in the code, but understood by a model. The model brings its knowledge of language and the world. It knows that a patient describing intense pain two days after surgery is not saying the same thing as a patient asking for an invoice. We simply no longer ask it to say so.

The published measurement is clear-cut. On an RTX 3090 card, with the exact same Qwen3.5-4B, the same situation, and the same 21 binary questions, direct score reading produced the 21 probability pairs in 1.023 seconds, without generating a single token. Having the same model write out a compact table of 21 values took 5.332 seconds, five times longer. The two readings agreed on 18 of the 21 questions, which the author honestly presents as a speed comparison, not as proof that the two methods decide the same thing.

He is just as honest about what is missing. Reversing the order of the options changed 10 answers out of 144 in his test set. And he writes that the probability obtained is a score conditional on the options provided, “not a calibrated operational confidence.” Neither of these two weaknesses is new: research described as early as 2021 that language models favor certain answers based on their position or frequency in the training text, and proposed corrections for it. Other open projects, released the same week, tackle this by fine-tuning a small model specifically for this output mode.

What SemIf shows is therefore limited, but conceptually important.

Why not just use classic machine learning?

At first glance, all this looks a lot like what we have known how to do for twenty years with logistic regression, random forests, or XGBoost, methods that learn to classify from labeled examples. And for one family of problems, these methods remain superior.

Suppose you want to estimate the risk of a complication after eye surgery from perfectly structured variables: age, intraocular pressure, corneal thickness, type of procedure, medical history. If you have several tens of thousands of properly filled-in records, calling on a four-billion-parameter model would be a poor starting hypothesis. A tree-based model is tiny, runs on an ordinary processor in a fraction of a millisecond, and learns precisely the statistical relationship you care about. A reference study from 2022 confirms this across 45 tabular datasets: trees remain ahead of neural networks on medium-sized data, even without counting their speed advantage.

Take a message received by a practice’s front desk: “I had surgery the day before yesterday, and since this morning I see much less clearly. My eye hurts a lot.” We want to choose between four possible next steps: an administrative reply, a normal appointment, a fast medical opinion, an emergency. To build a classic classifier, you have to gather enough messages, fix the categories, have each example annotated by someone who knows how to read a patient message, clean the data, train the model, then start over the day the practice changes its categories. Studies comparing the two approaches place the tipping point low, around a few hundred annotated examples: beyond that, a small fine-tuned model beats the large model used without examples. But below that point, and especially on day one, the large model is the only one that can answer at all.

A general-purpose model already has a representation of concepts like recent surgery, pain, loss of vision, or emergency. SemIf or Jev exploit that immediately, with no local dataset. Traditional machine learning learns your particular problem. The general-purpose model has already learned an approximate model of the world, and you tell it, in the request, which particular problem you want it to solve.

Categories move out of the model and into the program

This property becomes valuable in automation, because organizations change their minds. A classifier trained to sort between “spam,” “normal,” and “urgent” has learned those three classes. If the organization decides six months later to distinguish between the front desk, accounting, technical support, management, and emergencies, the problem has changed, and everything has to be re-annotated and retrained. A 2026 study on intent detection measures this bluntly: a fixed classifier scores zero on a new category scheme, whereas a general-purpose model keeps on answering.

The developer keeps the structure of the problem under their own control, in code they can read, test, and modify, and the model only supplies the part that is hard to write: understanding what the observed situation means. This brings artificial intelligence closer to ordinary software, and it is exactly the role we give it in our automation method: micro-processes where every step is legible, with the model stepping in only where a written rule is not enough.

What the second part explores

Let’s sum up. A generative model writes a text that the program then has to re-read to find a decision in it. A decision model receives the situation and the options, and returns a probability per option, in a single pass. The categories are no longer fixed inside the model; they are written into the program, where they can be read and changed. And this capability is not reserved for a closed service: SemIf shows that part of it already exists in an open model with four billion parameters, at the cost of limitations that its author documents himself.

All this would already make Jev or SemIf more flexible classifiers, and that would be useful in itself.

At that speed, the model enters loops where you observe, where you compare several actions before acting, and where a small specialized model ends up taking over the frequent cases. That is the subject of the second part of this article.

If you have a process where a decision comes up dozens of times a day and today relies on a person reading through it, a thirty-minute conversation is usually enough to work out whether a model of this kind fits it. Write to us at the bottom of the page, or book a slot directly in our calendar.

Sources

• TypeSafe AI, Introducing System One Models & Jev (15 September 2026)
  Official announcement: the three question types, parallel evaluation, the training method, latencies of 70 to 500 ms, the 114 ms example, and the price.

• TypeSafe AI, documentation: confidence
  Page describing the confidence score, which refers the user to their own measurements for calibration.

• Business Wire, TypeSafe AI Emerges From Stealth With $40M in Funding (15 September 2026)
  Launch press release: funding, founders, and positioning.

• Pear Pages, Jev, sorted: what TypeSafe’s System One model actually is, and what is still just a claim (16 September 2026)
  Critical analysis of the comparisons published by TypeSafe and the absence of calibration curves.

• Hacker News, discussion of the TypeSafe AI launch
  Reception among developers, including the objection that “it’s just a classifier.”

• Theodore Lee, SemIf (formerly OpenJev), GitHub repository
  Direct score-reading method, measurement of 1.023 s versus 5.332 s on an RTX 3090, perturbation tests, and limitations stated by the author.

• Zhao et al., Calibrate Before Use: Improving Few-Shot Performance of Language Models (ICML 2021)
  Position and frequency bias in language model answers, and a proposed correction.

• Zheng et al., Large Language Models Are Not Robust Multiple Choice Selectors (ICLR 2024)
  Sensitivity of models to the order and labeling of options.

• Grinsztajn, Oyallon, Varoquaux, Why do tree-based models still outperform deep learning on tabular data? (NeurIPS 2022)
  Reference for the superiority of trees on medium-sized tabular data.

• Bucher and Martini, Fine-Tuned ‘Small’ LLMs (Still) Significantly Outperform Zero-Shot Generative AI Models in Text Classification (2024)
  Tipping point around a few hundred annotated examples.

• When Do LLMs Replace Fine-Tuned NLU? A Decision Framework for Intent Detection in Production Conversational Systems (2026)
  Comparison under a changing category scheme: the fixed classifier stops responding.