Jev and the Case for a Model That Only Decides

Oliver Nowak

11 minutes ago

9 min read

Dark AI infographic titled Jev and the Case for a Model That Only Decides, with blue/orange flow to Routing, Priority, Review.

Some conditions are easy to write in software. If a basket contains three or more items, offer free delivery. Others are much harder. If you want to flag customer messages that sound frustrated, you can search for words like "angry" or "unacceptable", but a customer who writes "I've contacted you three times and I'm still waiting" hasn't used either of them, and anyone reading the message knows exactly how they feel.

That second kind of condition is what TypeSafe built Jev for. Released in early access on 15 September 2026, Jev is best thought of as a smart if statement: a model that reads a situation and returns a judgement your software can act on, without writing any prose. It has had a lot of attention in its first week, including a thoughtful piece from Laurie Voss that prompted this one.

What Jev Does

An application sends Jev two things. The first is what TypeSafe calls the state, which can be plain text, a JSON object or an array. In the example above, the state is the customer's message. The second is one or more questions about that state, and each question has one of three types:

Noul answers a yes or no question. Ask whether the customer sounds frustrated and it returns the probability that the answer is yes, so 0.94 leans strongly towards yes and 0.03 leans strongly towards no.
Choice picks from a list of options you define, such as asking for an update, requesting a refund, requesting a replacement or something else. It returns the selected option and a probability for every option.
Score places the state on a scale you describe. You define what each level means (makes a request without frustration, expresses dissatisfaction, expresses strong anger) and it returns a score weighted across those levels, so an answer can fall between two of them.

Several questions about the same state go into a single request, and Jev answers each one independently and in parallel. What comes back is typed data matched to the names you gave your questions. The model supplies the judgement and your application decides what happens next, whether that means flagging the message for the support team, routing it to a queue or leaving it alone.

TypeSafe calls this a System One model, borrowing Daniel Kahneman's distinction in Thinking, Fast and Slow between fast, intuitive judgement and slower, deliberate reasoning. The name comes from William Stanley Jevons, who noticed that more efficient steam engines increased total coal consumption, because cheaper running encouraged more use. TypeSafe's bet is that the same will happen with AI decisions: make them cheap enough and they get used in places where the cost never made sense before.

How It Differs From an LLM

Neon infographic comparing LLM and JEV: sequential text generation vs parallel decisions, with labels answer, choice, score, noul.

You can already ask a large language model whether a customer sounds frustrated, and ask for the answer as structured output. Functionally, very little of what Jev does is new. The difference lies in how the answer is produced.

A general purpose LLM generates text one token after another, and many models reason at length before committing to an answer. That is what you want when the output is an explanation, a reply or a block of code. When the useful output is one of four labels, it's a lot of machinery for a small question. Jev skips generation and produces the probabilities for its answers in a parallel pass, giving up the flexibility of text to make bounded decisions much faster.

There is a broader argument underneath this. For the past few years, the most capable models have been optimised for two things: being helpful to people in chat, and more recently being effective inside coding agents. Workflow automation has tended to get whatever those models could offer, at their cost and their speed. TypeSafe's position is that forcing a model built for conversation into high volume automation is the wrong starting point, and that this goes some way to explaining why so little everyday automation has followed years of impressive chat.

I think that argument is broadly right, although it's worth keeping the novelty in proportion. Narrow classification models were the normal way to do this kind of work before generative AI took over the conversation, and open source models built on similar ideas already run on ordinary hardware. What Jev appears to add is a general purpose version of that category, where you describe a new judgement in plain language instead of training a classifier on thousands of labelled examples first.

What the Early Numbers Show

TypeSafe reports end to end response times of roughly 70 to 500 milliseconds. Pricing is $0.042 per million input tokens, with output tokens free. To put that in practical terms, if a customer message and its questions come to around 500 tokens, a dollar covers roughly 47,000 checks.

On its own published evaluation across four multi-step workflows, TypeSafe reports that Jev matched its reference answers 67.8% of the time at an average of $0.0004 and 0.4 seconds per case, which it presents as about 194 times faster and 445 times cheaper than the models it compared against. Two caveats matter here. The reference answers are the averaged responses of two large models, so the test measures agreement with those models, not whether the underlying business decisions were correct. And TypeSafe itself says gains of that size are probably at the high end of what people will see in practice.

The independent tests so far are small and task specific. One exploratory email test found Jev reached 98.64% accuracy on 5,733 messages using written category definitions, against 98.87% for a conventional classifier trained on thousands of labelled messages. That is a strong result for a model that was never fitted to those labels, although the author notes the question wording was refined against earlier errors and the public data may have appeared in Jev's training. A separate intent classification study was more mixed. Jev beat a small LLM on one sample but trailed a larger one, and on a different task a small classifier trained on around 10,000 examples outperformed it.

For me, that justifies a serious look, but not yet a verdict. Jev can make useful decisions without a task specific training set, and it may offer a large speed and cost advantage where many bounded questions need answering. Whether that holds up depends heavily on the task and on what it's being compared with, and a cheap trained classifier belongs in that comparison as much as an LLM does.

Probabilities Are Only Useful If They Mean Something

TypeSafe trains Jev with a method it calls Reinforcement Learning for Calibrated Decisions, or RLCD. The intent is that a higher stated probability should mean a higher chance of being right. That matters because LLMs used as judges have a poor record here. As Voss points out, they tend to report confidence between 90% and 100% while being right considerably less often.

Calibrated probabilities are what make a decision model usable in a workflow. They allow a design where clear cases are handled automatically, uncertain ones go for review and the rest are left alone. But there is a technical distinction that is easy to miss. Choice and Score answers also return a confidence value, and that value summarises how concentrated the probabilities are. A confidence of 0.8 does not mean that eight in ten decisions above that level will be correct.

That has to be checked against real outcomes, task by task, before any threshold is trusted.

Why This Matters in ServiceNow

A great deal of ServiceNow work comes down to decisions made from imperfect information: what kind of record has arrived, who should own it, whether it resembles something already open and whether it needs attention now. Those decisions happen at high volume, delay directly affects the employee or customer waiting for help, and the rising cost of AI consumption makes it hard to justify a large generative model call for every one of them.

Incident assignment is the obvious example. A new ticket arrives with a short description, a service and perhaps a configuration item, and an assignment group is chosen before anyone has investigated. If that choice is wrong, the record moves between teams while the clock runs. Jev could make the first recommendation and return the spread of probabilities across possible groups, so the workflow acts on clear cases and holds the rest. The same pattern could apply to spotting an emerging major incident, scoring a customer case for escalation risk, matching duplicate records or checking whether an AI agent's proposed action is in scope, although each carries a very different cost when it gets things wrong.

Neon infographic of incident tickets flowing through first pass to assignment or human review, with service management decisions text.

The instinctive response is to say AI should only act when it's 90% sure. I'm not convinced that's the right starting point. How many decisions are organisations genuinely making at 90% confidence or higher? I'd argue very few. Service desk staff assign tickets on incomplete information every day, and a fair share of those decisions are corrected later. Before holding a model to an arbitrary bar, it makes more sense to measure what the current process achieves: how often tickets are reassigned, how long they take to reach the right team and which errors cause the most harm.

That points towards an escalation design. Cases where Jev's confidence falls below a threshold, perhaps 0.8 as a starting point for a reversible decision like first assignment, could go to an LLM that retrieves more context, reasons through the ambiguity and makes a fresh judgement, or to a person. Whether that second step improves the outcome enough to justify its extra time and cost is something to measure, not assume.

What It Has to Beat

ServiceNow already has Predictive Intelligence, which classifies and routes records and exposes confidence checks in workflows. Jev's advantage is that you can define a new judgement and its criteria without training a classifier on historical records first. That helps where the question changes often or good labels are scarce. Where a native classifier already works well, Jev may add nothing, and a trained model or a plain rule may be faster, cheaper and easier to govern.

It also can't be selected as one of ServiceNow's documented model providers, so a real test needs a designed integration with a clear data flow and a record of what the model decided and what happened next. Now Assist consumption is measured in assists, so a low external API price does not automatically reduce that bill, and the comparison has to cover the whole workflow, including integration, any extra model calls and human review.

Data governance belongs in the same conversation. TypeSafe's privacy policy says its service is hosted in the US and that customer input isn't used to train its models. Any organisation would still need to establish where its ticket data is processed, how long it's retained and which records it is prepared to send outside its current environment.

Where It Doesn't Fit

Jev doesn't write, so drafting a reply, summarising a case or generating code still needs a generative model. Nor should it replace logic you can calculate exactly. Counting items, comparing dates and applying a fixed business rule belong in code, and putting a probabilistic model in front of deterministic logic only adds a way for it to go wrong.

The absence of explanations is a bigger trade-off than it first looks. When an LLM gets a judgement wrong, you can at least read its reasoning and adjust the prompt. With Jev you get a number, so improving it means building representative test cases and measuring against them. A neatly typed answer can also be wrong, and if the right option was never offered, staying within the list doesn't help, which is why TypeSafe recommends including an "other" choice where a list may be incomplete.

Michal Bojko made the point that concerns me most, in a comment on Voss's article. Moving from sampling a small share of traffic with one AI judge to scoring all of it with dozens of small classifiers creates dozens of evaluators, each of which can drift without anyone noticing. The inference is cheap, but the monitoring and revalidation around it isn't, and that cost sits with the organisation, not the vendor.

Where I Would Start

I'd begin with one high volume, reversible decision such as incident assignment, and run Jev alongside the existing process without touching live records. Give both approaches the same information available at submission, test them on a period of incidents neither has been tuned against, and compare first choices, reassignments and time to reach the right team. Then compare Jev's confidence bands with what actually happened, and only after that add an LLM to the uncertain cases to see whether it earns its extra time and cost.

Jev is a week old, the published performance figures come mostly from the vendor, and a ServiceNow deployment raises integration and governance questions that no benchmark answers. But I suspect the underlying idea will outlast this particular model: most decisions in a workflow are small judgements that need to be fast, cheap and honest about their uncertainty.