# We Have 21 Decision Points in Production. Jev Would Change Six of Them

> TypeSafe AI's Jev returns typed decisions with calibrated probabilities, not text. We tested it against every decision node in our automation teardowns.

On 15 September, TypeSafe AI released a model that cannot hold a conversation. That is the point of it.

Jev takes a description of a situation and a list of allowed outcomes, and returns one of them, typed, with a calibrated probability attached. No prose, no chain of thought, no tokens streaming back. TypeSafe calls this new class a System One model, after the fast automatic half of the System 1 and System 2 split, and the claimed response time is **70ms to 500ms** against 3 to 329 seconds for frontier models on comparable tasks.

I am unusually well placed to check whether that matters, because we publish the decision logic of the automations we build. So I went and counted.

## What Jev actually is

Two things are architecturally different.

It is **non-autoregressive**. A parallel sampler generates all outputs in a single query instead of predicting one token, then the next, then the next. That is where the latency claim comes from, and it is a structural difference rather than a smaller model running on better hardware.

It is trained by something TypeSafe calls **Reinforcement Learning for Calibrated Decisions**, optimising for what they describe as answers with epistemically honest probabilities. The output is a type-safe structured value carrying a probability and a confidence score.

The advertised figures: **$0.042 per million input tokens**, output free, and **193.6x faster, 444.6x cheaper** on their own workflow evaluations. The stated use cases are smart if-statements inside AI-powered workflows, map-reduce over large data, real-time applications, and verifying or guardrailing the output of other models.

Note the trade it names openly. Jev gives up string generation. It is not a small language model. It is not a language model.

## Why I bothered checking

The tagline on our [AI automation practice](/services/ai-automation) is that automation should decide, not just trigger. We have [nine delivered systems published as full teardowns](/services/ai-automation/systems), every intake channel and every branch with the condition that fires it, because the decision logic is the part worth showing.

That means I can answer a question most people arguing about this model cannot: in real production automations, how many decision points would a System One model actually touch?

Our nine teardowns contain **21 nodes explicitly marked as decisions**. I went through all of them.

## Ten are rules wearing a decision's clothes

A checksum compared against the last crawl. A PIN validated against a company registry. A contact matched on exact email. Deduplication. A status lookup, twice. An attendance flag that is either true or false. A monitoring check. CRM conditions.

And my favourite, from the [construction bid pipeline](/services/ai-automation/systems/construction-bid-pipeline-handover): a gate that routes on how many hotels the enquirer operates. Eight or more goes to the owner's diary. Three to seven goes to business development. Zero to two, or an unreadable count, goes to a qualifying call.

That is a threshold. It executes in under a millisecond, costs nothing, never drifts, and any auditor can read it. Putting a probabilistic model behind it would make it slower, more expensive and less predictable in exchange for nothing at all.

I expect this to be the most common mistake of the next six months, and it will not be made by people who do not understand AI. It will be made by people who are excited about it.

## Three are human on purpose

An attorney reviewing a generated case video. A human approval gate before a release ships its content. A reviewer signing off a correction before it trains anything.

None of these are latency problems. They are accountability positions, deliberately placed where somebody needs to be answerable for the outcome. A model that decides in 70ms does not address the reason a person is standing there.

One more is retrieval rather than judgment, a semantic lookup in a vector store, which is a different job again.

## Six are real candidates

| Decision node          | System                    | What runs it today                                    |
| ---------------------- | ------------------------- | ----------------------------------------------------- |
| Attachment categorised | Release orchestration     | n8n branching across six attachment types             |
| Centre identified      | Multi-tenant WhatsApp     | n8n, and the answer becomes a tenant isolation filter |
| Validated and cleaned  | Multi-tenant WhatsApp     | A second AI agent checking the first                  |
| Purchase intent scored | Multi-tenant WhatsApp     | An AI agent, scored per message                       |
| Meeting type match     | Construction bid pipeline | n8n matching a recording to an appointment            |
| Family scored          | Competitor ad pipeline    | n8n scoring a creative family                         |

Six of 21. Not the number anyone launching a model would like, and it is the honest one.

There is a seventh I am deliberately not counting. An automated QC step in the ad pipeline runs on OpenAI vision, and it is the purest example of TypeSafe's own verify-everything use case: the machine checking the machine, with a human still deciding. But their announcement says nothing about image input, so counting it would be me assuming a capability into existence.

## Where calibration earns its keep

Two of those six are more interesting than the rest, and neither is about speed.

The [multi-tenant WhatsApp system](/services/ai-automation/systems/multi-tenant-whatsapp-qualification) scores purchase intent on every inbound message and appends each change to a score history rather than overwriting it, so a contact that warmed steadily reads differently from one that spiked once and went quiet. Intent is a running figure, not a final verdict. That design only works if the figure means something consistent over time, and an LLM's self-reported confidence number is mostly decorative. A genuinely calibrated probability is a different object: if it says 0.7 across a thousand messages, roughly seven hundred of them should have been right.

The construction bid pipeline has an edge whose firing condition reads, in our own published transcription, that nothing matches the recording with enough confidence to act on. That threshold already exists in the delivered system. It just lives implicitly inside prompt behaviour, where nobody can tune it or audit it. Calibrated output turns it into a number on a dial.

That, not latency, is the thing I would actually buy.

## The claim I would test first

**Cannot hallucinate is a statement about the output type, not the output correctness.**

If the model must choose one of six attachment categories, it will always return one of the six. It will never invent a seventh, never emit malformed output, never produce the fluent nonsense that breaks a pipeline downstream. TypeSafe's framing is fair here: a hallucinated tool call is inconvenient in a chat agent and a deal-breaker in a system with latency guarantees.

But it can still return the wrong one of the six. Type safety eliminates a class of integration failure. It does nothing about judgment failure. The calibrated probability is the part that speaks to judgment, and calibration is much harder to verify than type conformance, which is presumably why the marketing leads with the easy guarantee.

As for the benchmarks, 193.6x and 444.6x are vendor figures from vendor evaluations, with no published independent methodology and no third-party production reports, because the thing is in early access behind a waitlist. That is not an accusation, it is just what stage this is at. We have [written before about what happens](/blog/agentic-soc-2026) when an industry starts re-citing vendor numbers until they look like facts, and the way to avoid joining in is to label them while they are still fresh.

## What we are doing about it

Nothing dramatic, which is the recommendation.

The ten deterministic gates stay deterministic. The three human gates stay human. For the six candidates, the sane move is a shadow run: put Jev alongside what is already there, on real traffic, decide nothing with it, and compare both the decisions and the calibration against what the current implementation did. If the probabilities hold up over a few thousand real messages, the threshold-based routing gets meaningfully better and cheaper. If they do not, we learned that for the cost of an API key.

The broader point outlives this particular model. Most teams reaching for AI inside a workflow reach for a chat model, because that is the shape of AI they have met, and then wrap it in retries and parsers and validators to beat a structured answer out of it. A model class built to return decisions directly is the correct idea whether or not Jev is the one that wins.

The work is knowing which of your branch points is a judgment and which is a rule, and [most teams have never mapped that](/blog/ai-agents-that-reach-production).

We map it before we build. If you want to see what that looks like on a real system, the [teardowns](/services/ai-automation/systems) are all public, and if you want it done on yours, [book a discovery call](/contact).

_Part of our guide to [AI agent development](/blog/ai-agent-development)._

_Jev details from TypeSafe AI's announcement post, dated 15 September 2026, and its published pricing. All performance figures are vendor self-reported on vendor evaluations. Decision-node counts are taken from our own published teardowns as of 21 September 2026._