Jev is a decision model whose interface asks bounded questions about a supplied state and returns probabilities over the allowed answers. A support system might ask which queue should receive a ticket, whether a tool result actually resolved it, and how urgent it is. The application, rather than the model, decides what to do with those answers. In September 2026, TypeSafe introduced Jev for this kind of typed decision request, making an old systems question concrete: when the useful output is a small distribution, why generate a sentence to carry it?
The short answer is that Jev moves the boundary. A conventional language model can certainly emit {"route":"billing"}; strict structured output can make that object parse. Jev instead accepts the answer space as part of the question and returns the chosen answer and its distribution as the native result. Several questions can refer to one supplied state. That makes semantic judgments easier to place inside software, but it does not make their probabilities self-validating or authorize any action.
This is a model category worth understanding even if a particular workload ends up using rules, a fine-tuned classifier, or a constrained LLM. We will follow the interfaces first, then the computation they may avoid, the architecture that is and is not disclosed, and finally the policy that turns a judgment into a safe system decision.
In this deep dive
What Jev receives and returns
Why a separate decision model might help
What can be inferred about Jev's architecture
Calibration, RLCD, and action thresholds
Where Jev fits among existing tools
A system with generation and decision separated
One useful rule already follows from the interface: a model's answer should be treated as evidence about a defined outcome, while the application's code retains the choice of action. The rest of the article explains exactly what must be defined, computed, and checked before that rule is useful.
