Jev and the End of Prompt-and-Parse

My recommendation, stated before the evidence: build one real workload on TypeSafe's Jev, run it head-to-head against whatever hand-rolled heuristic already does that job, and score agreement, latency, and cost — before deciding it belongs anywhere that touches a client. Jev is worth that test. It is not, on the evidence available today, worth trusting on the vendor's word.

What "System One" actually replaces

Most AI features I build are not really language problems. They are decisions wearing a language problem's clothes: route this ticket to the right queue, rank these five candidates, pull one value out of this document, decide whether this claim is actually supported by that evidence. The usual way to build any of the four is prompt-and-parse — write a prompt, get back a paragraph or a blob of JSON, parse it, retry when the parse fails, and hope the model's phrasing doesn't drift under the next model upgrade.

TypeSafe's pitch is that this is the wrong primitive for the job. Its documentation describes "System One models" as a class built to make fast, structured decisions that software can use directly — they return typed decisions and probabilities rather than generated text. Jev is the first of these: not a chat model, not a reasoning model, a decision model. You do not get back prose to parse. You get back a typed answer and a number.

That framing matters more than the branding suggests. A model that generates text has to be coerced into a schema after the fact, with a parser standing between the model and your code, silently absorbing the cases where the shape doesn't match. A model whose job description is "return a typed answer" removes that seam, if it does what it says.

Three primitives, and where the workflow actually lives

TypeSafe's docs define three question types, and the discipline underneath them is the actual pitch, not the count of three:

Choice — pick one of a defined set of options. Returns the choice, a probability distribution across the full option set, and a confidence score.
Score — a position along an ordered, described dimension (severity, frustration, skill level). Returns the score, a legend for what each level means, and confidence.
Noul — the probability that a stated condition holds, 0 to 1. No separate confidence figure; a Noul near 0.5 means the model finds yes and no equally likely, not "medium intensity."

The part I'd flag for anyone reading this as a spec rather than a pitch: the docs are explicit that code owns the workflow. Rules, arithmetic, thresholds, retries — all of that stays in ordinary code. The model supplies one narrow judgment per question, several of which can run in parallel over the same state, and code composes the answers afterward. That is the real difference from prompt-and-parse. It isn't that the model got better at following instructions. It's that the boundary between "what the model decides" and "what code decides" got drawn much narrower, on purpose.

A minimal call, per TypeSafe's own API reference, looks like this:

POST /v1/systemone
{
  "state": { "ticket": { "subject": "Refund not received", "body": "..." } },
  "model": "jev-latest",
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "Which team should handle this ticket?",
      "criteria": { "billing": "...", "technical": "...", "general": "..." }
    }
  }
}

The response carries choice, a probabilities map across every option TypeSafe was given, and a confidence figure — three fields code can act on directly, with no parsing step between the model and the decision.

The numbers, stated as the vendor's, not mine

TypeSafe exited stealth on 2026-09-15 with a $40M seed round led by DCVC. The founding team is Diogo Almeida — a former OpenAI researcher credited as a co-inventor of RLHF and a contributor to InstructGPT, ChatGPT, and GPT-4 — alongside Erik Gafni and Sasha Sheng. That's a credible team making a specific bet: that the next useful AI-application primitive isn't a bigger model, it's a typed one.

The performance numbers are TypeSafe's own, self-benchmarked, and I want to say that plainly rather than let a number read as independently verified when it isn't:

Latency under 100 milliseconds, described by TypeSafe as up to 100 times faster than comparable frontier-model calls for the same decision.
Pricing of $0.042 per million input tokens, with output tokens free — TypeSafe frames that as roughly 238x lower than a comparable frontier model's input rate.
One worked example published on their own site: a routing workflow completed in 0.114 seconds for $0.000081, against a comparable LLM-based pipeline at 8.566 seconds for $0.013880 on the same task.

Those are large gaps, and they're the kind of gap I'd expect from a model that returns three typed fields instead of a paragraph — less to generate, less to parse, fewer retries. I'm not disputing the direction. I'm saying the company that ran the benchmark is the company selling the model, and I haven't run a byte of my own traffic through it yet, so none of these numbers are mine to claim until I have.

"Zero hallucinations" is a narrower promise than it sounds

TypeSafe's homepage states "Zero Hallucinations." Read against their own documentation, that claim is doing less work than it sounds like, and the docs say so themselves: "Typed output guarantees the interface, not truth. System One models are trained for calibrated decisions; validate their performance in the target domain."

That's the correct distinction, and it's worth keeping separate from the marketing line rather than repeating the marketing line as if it had settled the question. A Choice question cannot return an option outside the set you gave it — the schema is guaranteed. Whether the option it picks is the right one is a different claim entirely, and it's the one the confidence score exists to help manage, not the one "zero hallucinations" answers. A model that never fails to parse can still be confidently wrong. Calibration is a statement about the relationship between confidence and accuracy across many decisions; it says nothing about the single decision in front of you right now. Reading a vendor's headline claim as a promise and checking what the fine print actually commits to is the same habit I've written about for checks with names that overpromise — this is that pattern one level up, in marketing rather than code.

Where I'd actually use this

Inside my own system, I already have three problems shaped exactly like Choice and Noul, each currently costing more than it should:

An event classifier with known coverage gaps — a Choice-over-a-defined-set problem, today handled by pattern rules that miss cases their author never anticipated.
Two subagent judgments — "is this candidate a real conflict," "is this pattern really recurring" — that currently cost a full LLM subagent turn each to answer what is structurally a Noul with a threshold.
A gate-scoring step that already reduces to ordered levels, which is a Score problem wearing a hand-written rubric.

None of these touch a client. That's deliberate. The validation plan I'd run before trusting Jev anywhere client-facing is the same for all three: same corpus, same task, TypeSafe against the incumbent heuristic, scored on agreement with the current decision, latency, and cost per decision, on real traffic rather than authored examples — the same discipline I've argued for in how AI evals should be built: measure what the work actually needed, not just whether the software behaved. A win on two of three axes, with no regression on the third, is what would move this out of "on-hold, experimenting" and into something I'd actually ship.

What I'd do

Pick one internal, read-only judging task with a hand-written heuristic already in place — a replacement for a decision that exists, not a new capability.
Build the TypeSafe version alongside the incumbent, not instead of it, for the length of the test.
Score both on the same real corpus: agreement with the current decision, latency, and cost per decision — my own numbers, not TypeSafe's benchmark.
Treat the confidence score as a routing signal for escalation, never as permission to skip a check on a low-confidence answer.
Keep it off anything client-facing until a head-to-head win on two of three axes, with no regression on the third, and re-check pricing and data-retention terms before any client-adjacent data touches it — the company is weeks old in public terms, and terms that are fine for an internal experiment may not be fine for a client's data.