Jev use cases: where a decision model fits in real software

TypeSafe's own map of jev use cases runs to nineteen industries, from insurance claims to gaming chat. Underneath them it lists only ten decision shapes, and every industry example is one of those ten wearing a domain's vocabulary. That is the useful way to read the map: stop asking whether Jev suits your sector and start asking whether your workflow contains one of ten shapes.

This post walks the shapes that pay, the ones our own work keeps running into, and the two cases where the honest answer is a rules engine or a language model instead. Every figure is linked to the page it came from.

The jev use cases worth knowing are shapes, not industries

Jev is a decision model: it takes a state and typed questions and returns a choice, a score or a probability, with confidence, instead of text. TypeSafe's use-case map groups the work into ten task categories. Find yours here before you look for your industry.

Decision shape	Reach for it when	Typical examples
Classification	One known category should win	Intent, department, risk type
Detection	You need a probability that a property is present	Spam, fraud, urgency, jailbreaks
Scoring	The answer belongs on an ordered rubric	Severity, relevance, quality
Routing	A category selects the next code path	Escalation, model routing, queues
Search and retrieval	You need the items matching a plain-language query	RAG context, document discovery
Ranking	Items need ordering by semantic relevance	Search results, recommendations
Verification	An artefact must be checked for specific failure modes	Citation support, tool-call errors
Feature extraction	A classical ML model needs semantic signals	Purchase intent, churn signals
Structured extraction	Known fields must be recovered from free text	Order fields, document labels

The test for each row is the same: the answer set is fixed before the call, and the answer is consumed by code rather than read by a person. A Choice question accepts up to 255 options, and TypeSafe advises sending the whole list of teams or categories rather than a shortlist, plus an other option so the model can say none of them fit.

Where a decision model earns its place in real software

Triage, and the whole decision tree in one call

Support triage is the canonical case because the decision is genuinely several decisions. TypeSafe's speculative fan-out pattern asks five questions of one ticket at once: category, bug severity, whether reproducible steps are present, whether a refund was requested, and how frustrated the customer sounds. Severity and repro steps only matter if the ticket is a bug report; the refund flag only matters for billing. All five are asked anyway, because questions run in parallel against the same state and the irrelevant answers are discarded in code.

The same shape covers insurance first-notice-of-loss, recruiting screens, lead qualification and claims prioritisation. In each, the map's advice is identical: classify, score, detect, then escalate uncertain cases for human review rather than force a verdict.

Moderation, where confidence is half the decision

For trust and safety the map's phrasing is worth copying verbatim: combine severity and confidence to allow, warn, review or block. That is two axes, not one. A high severity reading the model is unsure about is a different case from a high severity reading it is certain about, and only a model that reports calibrated uncertainty lets your code tell them apart. TypeSafe notes that calibration is measured across groups of predictions and does not guarantee any individual answer is correct, which is exactly why the threshold belongs in your code.

Guardrails and verification on top of other AI

The use-case map's universal verification category is the one teams underrate. You can check an LLM's input, output and tool calls with typed questions at a fraction of the cost of the generating call: jailbreak and prompt-injection detection, policy violations, sensitive-data exposure, citation errors, tool-call errors.

TypeSafe's build guide shows the mechanics on a tool-call trace. The bad version asks one question, "is this trace correct?". The good version asks nine: does the tool name suit the request, do the arguments conform to the declared schema, do the coordinates in the second call match the output of the first, does the unit match what was asked. Nine narrow answers tell you which part broke. One broad answer tells you only that something did. If you are already running an evaluator model over generated output, the biases we catalogued in LLM-as-a-judge evaluation apply to that evaluator, and a typed check on a fixed answer space avoids several of them by construction.

Retrieval and re-ranking, where the numbers are published

Re-ranking is the use case with the clearest published evidence. TypeSafe's cookbook builds 30-passage BM25 shortlists for 40 CLERC legal queries over 3,565 court opinion passages, then asks one question per query-candidate pair. It reports top-1 accuracy rising from 5% to 18% and top-10 from 38% to 62%. Treat that as a demonstration on a public legal dataset, not a promise about your corpus, but it shows the shape: cheap keyword search proposes, the decision model disposes.

Features for a model that already exists

The least obvious use case is the one where Jev is not making the decision at all. Probabilities extracted from free text become numeric features for a classical model you already train: purchase intent from sales notes, supply concerns from support tickets, competitive pressure from market reports, fed into a forecasting model alongside historical time series. Teams who have labelled outcome data and a working gradient-boosted model often get more from this than from replacing anything.

What the smart home demo shows about pairing Jev with an LLM

The pairing question comes up in every scoping conversation, and TypeSafe's smart home assistant demo answers it better than any diagram. A request such as "turn off all of the lights in the house" is resolved by typed questions: what category of request, what domain, what device type, what action. The action question is asked before the system knows the request concerns lights at all.

Two branches hand off to a language model. A Noul question detects whether the request contains more than one distinct action; if it does, an LLM splits it into atomic commands which are then evaluated individually. And when the request turns out to be general conversation rather than a command, an LLM writes the reply. TypeSafe's own note is that the decision response is fast enough relative to the LLM that it adds negligible latency to the whole system.

That is the division of labour worth designing for. The decision model decides; your code acts; the language model writes only the part a human is going to read. Keeping that boundary explicit also keeps your traces legible, which matters for the cost and session controls we cover in AI agent observability.

When a plain rules engine is still the right answer

This is the section most vendor pages skip. If you can write the rule down as a rule, write it as a rule. TypeSafe's build guide opens by doing exactly that: an invoice goes to collections when it is more than thirty days overdue, in four lines, no model involved. Its first design step is "use code when you can".

The honest boundary is whether the criterion is expressible in the data you already hold. Overdue days, order value, plan tier, country, SLA breached: these are columns. A rules engine evaluating columns is faster, free, auditable and testable, and it does not need a confidence threshold. Putting a model in front of it adds a network call, a bill and a new failure mode in exchange for nothing.

Two more cases where the model is the wrong tool. Multi-step arithmetic and multi-hop chains need working memory a single fast judgment does not have; decompose them into several questions or send them to a reasoning model. And non-English traffic needs testing first, because TypeSafe states that English is its primary training language and where accuracy is currently best, with other languages including CJK scripts handled but not equally well.

When an LLM is still the right answer

Whenever the output is prose a person reads, an LLM writes it. Drafting the reply, summarising a thread, explaining a decision to a customer, generating code: none of these have a fixed answer set, so nothing is gained by constraining them and a great deal is lost.

The same goes for open-ended extraction where you do not know the fields in advance, and for anything needing a chain of reasoning you want to inspect. Jev returns no explanation because it generates no text; if your compliance process requires a rationale in the record, you will be pairing it with something that writes one. We set out the full comparison in when a decision model beats an LLM, including the cases where it clearly does not.

How to tell if your workflow has a Jev-shaped decision in it

Four questions, in order. Can you write the answer set down before the call, as options, levels or a yes/no? Will code consume the answer rather than a person reading it? Can you state the criteria for each option in a sentence, including what it is not for? And is the input text, or reducible to text, since images, audio and video are not accepted as state?

Four yeses means the decision is typed and the rest is engineering. One no is usually informative: if you cannot write the criteria down, the problem is that the policy has never been agreed, and no model fixes that. That conversation, held before anyone writes an integration, is the most valuable hour in the project, and it is where we start on this kind of custom software work.