How Jev AI Works: System One Models and RLCD

Last verified September 20, 2026.

What happens when Jev receives a request

A request has three parts: the model, the state, and the questions.

State is the thing being judged. An email body, a support ticket with its metadata, a row from a spreadsheet, a snapshot of a game. It can be structured or unstructured, and Jev reads it either way.

Questions are what you want to know about that state, each one declared as a Choice, a Score or a Noul. You define the permitted answers up front. That declaration is not a hint — it is the boundary of what can come back.

The model prefills the state once and evaluates every question against it. The answers return together, each with a probability.

The three primitives

Those limits are worth designing around. A Choice with 255 options is a lot of room, but a Score capped at 10 levels means you cannot ask for a 0–100 rating in one question. If you want finer granularity you compose it — several narrower questions, combined in your own code.

Why the questions run in parallel

This is the architectural difference, and it is the reason the latency figures look the way they do.

An autoregressive model generates one token, conditions on it, generates the next. Every token waits for the one before it. Ask for a longer answer and you wait longer, because length and time are the same axis.

Jev's questions do not condition on each other. Each is evaluated against the shared state, so they can be computed together, not in sequence. TypeSafe reports that adding questions has relatively little impact on response latency for exactly this reason. Published latency runs 70 to 500 ms, against comparison models TypeSafe measured at 3 to 329 seconds on the same workflows.

The context budget, properly

There are two numbers and they are not the same number.

• 32K — your state plus the longest single question.
• 64K — the total for the whole request, across every question asked against that state.

Most coverage reports 32K alone, which quietly understates the design. The model exists to be asked many things about one block of state in a single pass, and the 64K figure is the budget for doing that. If you plan against 32K only, you will split work into multiple calls and pay to prefill the same state repeatedly.

What RLCD is, and what it does not prove

TypeSafe trains Jev with a method it calls Reinforcement Learning for Calibrated Decisions. The stated goal is in the name: not just to be right often, but to be calibrated — for the stated confidence to track the real hit rate, so that when the model says 80%, roughly 80% of those cases turn out to be true.

Calibration is what makes a threshold meaningful. "Automate above 0.9, escalate below it" is only a sensible policy if 0.9 means something stable.

Here is the honest state of the public evidence: no calibration curve or expected-calibration-error figure appears in TypeSafe's public documentation as of September 20, 2026. The threshold guidance in its documentation is a comment in an example — "YES = 0.5 (up to you on what you want the threshold to be, depends on your usecase)."

So RLCD describes the training objective. It is not, on the public record, a demonstrated property you can cite. Which means the measurement has to happen at your end, against your own labeled data, before you let a threshold decide anything that matters.

Probability is not confidence, and neither is correctness

Three different things travel in a Jev response and they are easy to conflate.

The probability on a Noul is the model's estimate that the statement is true. The distribution on a Choice shows how the mass is spread across the permitted options — 84/15/1 is a different situation from 40/38/22, even though both return the same top answer. And correctness is whether the answer matched reality, which no response can tell you and only a labeled comparison can.

A flat distribution is the most useful signal in the payload. It is the model saying the input did not clearly belong anywhere, and it is exactly the case you want routed to a person rather than resolved by a tie-break.

The schema guarantee, stated precisely

Because you declare the permitted answers, Jev structurally cannot return something outside them. It cannot invent a department that was not in your list. That eliminates a real class of failure that anyone who has parsed JSON out of a language model has fought with.

It does not make the chosen answer right. TypeSafe's own wording is that schema matching is guaranteed and the zero-hallucination number is not empirical. Both halves of that sentence are load-bearing. You get a guarantee about the shape of the answer and no guarantee about its content.

Decompose the reasoning, compose in code

TypeSafe's own recommendation is to split a complex judgment into several narrow questions and combine the results in ordinary code, not as one large question.

Consider deciding whether a support ticket should be escalated. As one question it is a judgment with a fuzzy boundary. As four it is tractable: is the customer asking for a refund, how frustrated do they sound, is this the third message in the thread, does the account exceed a value threshold. Jev answers each, and your code combines them with rules you can read, change and test.

That split has a side effect worth naming. The composition logic lives in your codebase, in plain code, where it can be version-controlled and argued about — not inside a prompt where nobody can see it.

Where this architecture fails

Parallel evaluation against a shared state is fast because it is shallow. The failure modes follow from that directly: chains of inference across several connected facts, anything requiring outside lookup, and anything where the answer depends on an earlier answer. TypeSafe documents these and several more, and we cover all nine in When Not to Trust Jev.

The short version: if the hard part of your task is connecting things, this is not the right level. If the hard part is deciding among things you can already name, it is.