JEV PATTERNS

THE SHAPE EVERY JEV PATTERN SHARES

TypeSafe's own documentation draws the architecture as a single column: unstructured state flows into typed questions, typed questions flow into Jev, Jev returns choices, scores and nouls with their distributions, and deterministic composition in code splits the result into a reversible action on one side and a review or fallback path on the other.

The interesting word in that diagram is reversible. Every Jev pattern below assumes that whatever Jev's answer triggers can be undone, retried, or escalated. Jev is a fast, cheap, well-calibrated guesser, and the correct place to put a fast cheap guesser is in front of a decision that tolerates being wrong occasionally — never behind one that does not.

TypeSafe states the boundary plainly: Jev should answer questions like which known route fits this request, how severe is this issue on this rubric, is this message asking for a refund, does this passage support that claim. Jev should not be the only thing deciding whether an account is deleted, a payment is sent, or any high-impact action is finalised.

WHY JEV PATTERNS EXIST AT ALL

A model with three question types and no text output sounds like it should need no Jev patterns at all. In practice the opposite is true, because the constraint pushes all the design work into a place most people are not used to thinking about: the shape of the question itself.

With a chat model you can be vague and let the model sort it out. With Jev you cannot. Every option has to be named, every rubric level has to be described, and every threshold has to be chosen by you rather than implied by a prompt. Getting that right is a skill, and these Jev patterns are the accumulated answers to questions people kept getting wrong in the first week.

The second reason is composition. A single Jev question is rarely interesting on its own. What makes Jev worth adopting is asking six questions about one state in a single parallel request, then writing the twenty lines of routing logic that turn six probabilities into one action. A Jev pattern is mostly about that second half — the part Jev does not do for you.

CHOOSING THE RIGHT JEV PATTERN

Start from what your program already knows. If it has a fixed set of destinations and needs to pick one, you want a routing Jev pattern, and the only real design work is naming the destinations precisely enough that they do not overlap. If it has one thing and needs to know how bad it is, you want a scoring Jev pattern with a described rubric. If it has a proposed action and needs permission, you want a guardrail Jev pattern built from Nouls.

If you cannot tell which of those you have, that is usually a sign the decision is not yet crisp enough to give Jev. Write down the exact set of answers you would accept. If the list is open-ended, Jev is the wrong tool and a text model is the right one. If the list is closed, you have just designed your Jev question.

A useful second filter is volume. Every Jev pattern here is worth the engineering only when the decision runs often. A judgement your system makes twice a day can stay on whatever model you already pay for; the case for Jev is built on the thousandth call, not the first.

DESIGNING THE QUESTIONS A JEV PATTERN NEEDS

The single highest-leverage habit is to describe options rather than label them. A Jev Choice whose options are bug, billing and other performs noticeably worse than one whose options carry a sentence each — a product defect, outage or integration failure; a charge, refund, invoice or subscription issue; none of the above clearly fits. The model is reading your descriptions, so vague descriptions produce vague decisions.

The second habit is to give Jev an escape hatch. Almost every Choice should include an explicit none-of-these option, because forcing a model to pick from a list that does not contain the right answer guarantees a confident wrong answer. Pair that with a confidence floor in code and the ambiguous cases route themselves to review instead of guessing.

The third is to keep each Jev question about one thing. If you find yourself writing an option set where two options differ along two independent axes, you have two questions. Split them. Because Jev evaluates in parallel, splitting costs you almost nothing and usually improves both answers.

Finally, point Jev at the specific part of the state that matters. The playbook's own examples reference fields explicitly — ticket.messages[0].text rather than the whole object — and that precision tightens the answer considerably when the state is large.

WHERE JEV THRESHOLDS BELONG

In code, always, and written as constants you can find and change. The temptation is to bury a confidence cutoff inside a helper or, worse, to try to express it in the instructions you give Jev. Neither survives contact with production, because the number you actually want is discovered by watching real traffic, not by reasoning in advance.

The pattern that works is a small, explicit ladder. Above a high threshold, act automatically. Between the two thresholds, take the action but flag it for sampling. Below the low threshold, do not act — route to a human, or fall back to the expensive model you were trying to avoid calling.

Because Jev is trained for calibration, these numbers mean something. A 0.9 from Jev should be right roughly nine times in ten, which is what lets you reason about the cost of the ten percent instead of guessing at it. That property is the actual product, more than the speed and more than the price.

One caution worth repeating: calibration is a statistical promise about many calls, not a guarantee about any single one. Jev can be confidently wrong on an individual case, and it will give you no explanation when it is. Build the sampling in from the start.

WHICH JEV PATTERN TO START WITH

If you are picking one Jev pattern to implement first, pick the guardrail Jev pattern. It is the smallest, it is a single Noul, it never blocks anything on its own, and it gives you real traffic to calibrate a threshold against before you trust Jev with anything that matters.

From there the natural second step is routing, because that is where the money is: a Jev call in front of an expensive model, deciding how much of that model each request actually deserves. The cost saving there is not the twenty percent you get from a cheaper vendor, it is the ninety percent you get from not making the expensive call at all.

Every Jev pattern on this page is adapted from the community playbook, and each Jev pattern has its own page here with the full state, the typed questions and the routing policy written out. They are meant to be read and copied, not admired.