TypeSafe’s release of Jev and its training approach, Reinforcement Learning for Calibrated Decisions (RLCD), starts from a different assumption about how AI will be used in software.
Most language models are optimized to generate strings. Jev is designed to take state and return constrained, typed decisions with probabilities and confidence estimates. TypeSafe describes this as a “System One” model: fast judgment intended to sit inside software rather than primarily converse with a person. TypeSafe calls this a model for decisions, not tokens.
That distinction matters if the goal is to build AI systems whose permissions, escalation paths, actions and evidence remain explicit rather than disappearing inside a model. That is also the problem RunTime is intended to address.
A small experiment
We built a deliberately narrow benchmark to explore this. The model receives a deterministic rule system:
source_a → signal_a ─┐
├→ relation → gate → decision
source_b → signal_b ─┘
It is given only the starting inputs and, in some cases, an intervention such as SET(signal_a=high). It then has to compute the final decision.
The benchmark increases the number of dependent rule applications from easy, to medium, to hard. Every answer has an exact Python-computed ground truth.
We also ran each problem in two forms. One uses human-readable names such as signal, gate and decision. The other replaces them with arbitrary tokens such as Q7, R4 and P6.
The underlying computation is unchanged. The second condition tells us something about how well the model follows the supplied structure when the labels themselves provide very little help.
The complete standalone uv benchmark—including the case generator, exact oracle and OpenRouter harness—is embedded below. The collapsed view shows the opening and closing lines; expand it to inspect or copy the full Python source.
What we found
We compared Jev 1.13 with GPT-5 Nano across 72 cases.
| Representation | Jev | GPT-5 Nano |
|---|---|---|
| Human-readable labels | 90.3% | 98.6% |
| Opaque labels | 70.8% | 86.1% |
On the human-readable version, Nano solved 71/72 cases and Jev solved 65/72. Jev averaged about 0.29 seconds per decision versus 4.58 seconds for Nano in this run.
The interesting part is not simply which model scored higher.
- Jev can perform genuine rule execution. On shallow opaque problems it performed extremely well, even though the variable names had no useful meaning.
- Deeper composition matters. Jev degraded more quickly as additional dependent reasoning steps were introduced. Nano was more robust overall on the opaque systems.
- Representation matters a great deal. Both models improved when the exact same logical structures were expressed with clearer labels. Jev moved from 70.8% to 90.3%; Nano from 86.1% to 98.6%.
So “reasoning ability” is not a single number. It depends partly on the computation and partly on how that computation is represented.
Why this matters for verifiable AI
This experiment reinforced a fairly practical architectural point: an AI system does not necessarily need one model to do everything.
Some decisions may be shallow, structured and frequent. A fast decision model may be sufficient. Other decisions may involve longer chains, ambiguity or unfamiliar structure and justify a larger reasoning model. And some decisions should not be delegated to a model at all.
state ↓ controlled workflow ├── structured decision → specialist model ├── deeper reasoning → larger model ├── deterministic rule → code └── high-risk case → human ↓ policy / authority check ↓ action ↓ evidence
RLCD is interesting in this context because it introduces another useful computational primitive: fast, typed, probability-aware judgment. TypeSafe explicitly positions Jev as something software can branch on rather than as another text generator.
But our small test also shows why that judgment should still live inside a wider control system. Model reliability varies with task structure, depth and representation.
As specialized decision models improve, that separation may become increasingly useful. The embedded benchmark can be reproduced directly, modified to change the rule depth, or extended to test another model.
Method note. Results shown are from this benchmark’s 72 deterministic cases in each representation. Timing reflects this run and should not be treated as a general latency guarantee. Jev and RLCD descriptions refer to TypeSafe’s published introduction linked above.