Analysis · no invented benchmarks
Jev vs. chat models: what a typed decision model changes
Jev and a chat LLM can both answer a question — but they answer in different shapes, at different points in a program, and they fail in different ways. This page compares the two approaches on dimensions that can be observed in public code and public positioning, and it deliberately avoids performance tables, because none of those numbers has been independently reproduced. Everything here is grounded in the 30 records in our capability directory.
The output is a value, not a message
A chat model produces text meant for a person to read. To use that text inside a program, developers wrap it in schema prompts, JSON extraction, and repair logic, and accept that the contract is a convention rather than a type. Jev inverts the default: the answer to a narrow question arrives as a typed decision — an operation choice, a target choice, a relevance score, a match verdict — with a stated confidence, produced so that code can branch on it directly.
In the records we index, that shape is what lets the surrounding programs stay small and strict. The metasearch front end reads an enum of queries and sources; the Mario controller reads one chosen macro; the compaction plugin reads paired keep/truncate verdicts per tool call. Nobody parses prose in the critical path, because the model never emits prose in the critical path.
Narrow questions instead of open tasks
A chat model is given an open task and improvises a plan. The Jev pattern documented across the directory is the opposite split of responsibilities: deterministic code owns the loop, the permissions, the thresholds, the validation, and the side effects, and the model owns one bounded judgment at a defined point in that loop — pick the next action, rate the candidate, route the request, accept or reject the match.
This is not a limitation being spun as a feature; it changes what you can do with the output. A bounded answer among enumerable options can be validated, logged, replayed, and attributed after the fact. Theemulator controller record is a clean example: the set of legal macros is small, so a wrong choice is visible and reproducible, while frame-level execution stays entirely in code.
Different failure modes: and confidence is not correctness
Chat models fail in a well-known way: fluent prose that is wrong. Typed decision models narrow the surface — the answer is always one of the legal values — but they do not remove error, they relocate it. A wrong judgment now looks like a confidently wrong enum or score, which is more convenient to consume and no more trustworthy.
That is why every record in this directory treats confidence as a claim, not a proof. The MCP screening record states it as policy: screening is not a security or authorization boundary, and confidence is not correctness. The same discipline applies to vendor claims in the other direction — TypeSafe's homepage reports that Jev eliminates hallucinations and runs dramatically faster and cheaper than chat LLMs, and those remain reported vendor numbers that we have not reproduced.
Where each one fits, per the 30 records
Across the directory, the working pattern is consistent: use a chat model where the product needs open-ended language — drafting, explaining, summarizing, conversation — and use a typed decision model where software needs a high-frequency, bounded judgment inside a deterministic loop. The 30 public records split evenly enough to read as a map: control loops (a game controller, a macOS agent driven from screen state), ranking and filtering (search results, stale tool history), routing (smart-home requests, code review investigations), and verification (citations checked against sources). 3 of the records are TypeSafe's own examples; the rest are community projects, which is itself evidence that the pattern generalizes beyond the vendor's demos.
The honest counterpoint: in most of these projects a hand-written heuristic or a single wrapped chat prompt could have played the same role. What the typed model changes is the contract — decisions that arrive pre-validated, with confidence attached, at a cost and latency profile the vendor claims makes per-item judgment economical. Whether that economic claim holds at production scale is exactly the kind of question this directory exists to track, one verified record at a time.
What we did not compare, and why
You will not find accuracy tables, latency charts, or cost curves on this page. Those require controlled experiments on identical tasks, and none have been published by an independent party — assembling numbers from vendor marketing would just be marketing with extra steps. If you reproduce one of the indexed projects and publish measurements, send it in: records with independently reproduced metrics are exactly what the evidence levels here are designed to promote.
For what Jev is, start with the explainer page. For what it has actually been shown doing, browse the capability directory. To add public evidence, use the submission form.