Guide

Should your product use a decision model? A guide for founders and CTOs

A decision model answers a fixed question about a piece of text with a probability, in under half a second, at a price TypeSafe lists as $0.042 per million input tokens. It writes nothing. That makes it the right tool for a narrow set of product features, the wrong tool for most others, and a governance question either way. This guide is written for the person who approves the decision: how to sort features, how to run a two-week pilot, what to ask a vendor or partner, and how to keep the model auditable once it is in production.

Published September 22, 2026. Editorial.

Key takeaways

A decision model fits a feature when the answers are known in advance, the decision repeats at volume, nobody needs a written reason, and the input is text. Drafting, summarising, counting and date logic stay with a language model, rules or a person.
Do the cost arithmetic per decision, at your real monthly volume, and label every figure as the vendor's own. At one million decisions a month TypeSafe's benchmark figures separate by four orders of magnitude; at ten decisions a day the saving is a few dollars.
Jev is one week old at writing, from one vendor, on one hosted API, in one model version. Keep the questions, thresholds and labelled test set in your own repository so the decision layer can be swapped.
Run a two-week pilot in shadow mode with 100 to 200 labelled cases and decide on agreement, latency and cost against cutoffs you wrote down before the run.
Reveneau builds products and agents, uses Jev at their decision points, and grades its own eval suite with Jev, which runs ten times faster than it did with a language model grading it. We take responsibility for the project through production and after release.

Every product that uses AI makes two kinds of decisions. Some produce something new: a paragraph, a summary, a block of code, a reply to a customer. Others produce a choice from a fixed list: route this ticket to billing or to support, block this message or let it through, mark this document as complete or send it back. Until this month both kinds went to the same tool, a large language model, because it was the only tool that could read text and answer. The second kind now has a tool of its own.

TypeSafe AI released Jev on 15 September 2026 and called it a System One model, "a new class of frontier models built to make fast, structured decisions that software can use directly" [1]. It takes a piece of text and a set of named questions, and it returns a typed answer to each question with a probability. It does not write. TypeSafe lists its price at $0.042 per million input tokens with output free [2], and reports end-to-end latency of 70 to 500 milliseconds [1]. The waitlist came off on 20 September, so anyone can sign up [3].

This guide is for the person who has to decide whether a product should use it, and who will be accountable for the result: a founder, a product lead, a CTO, or an investor reading a portfolio company's plan. It does not contain code. The engineering detail lives in three neighbouring guides, what a System One model is, grading an eval suite with Jev, and running Jev in production. Here the questions are the buyer's: does this fit, what does it cost, how do we try it without betting the product on it, what do we ask a vendor, and how do we govern a decision that comes with no written reason.

The short answer is that a decision model fits a narrow set of features well, and the work of adopting one is mostly the work of deciding which features those are, and of designing so the model can be replaced. Everything below is detail on that answer.

What a decision model does, in one paragraph

A language model is a text generator. You give it a prompt and it writes a reply, one word at a time, and if you want a decision you read the decision out of the reply. A decision model skips the writing. The input is a "state", which TypeSafe defines as a string, a JSON object, or an array of text values, plus a map of named questions; the output is a typed answer per question with probabilities [4]. Three question shapes exist. A Choice picks one option from up to 255 and returns a probability for each. A Score places the state on an ordered scale of 2 to 10 levels described in words. A Noul is a yes-or-no statement that returns one probability from 0 to 1 [4]. Every question in a request is evaluated at the same time, so adding a question "barely changes the response time" [5].

TypeSafe says Jev "can't hallucinate", and the phrase needs its qualifier every time it is repeated: it means the answer always fits the schema you asked for, so the structured-output error rate is zero. The answer can still be wrong [1]. A model that always returns a valid probability is easier to build software around, and it can still be wrong.

Which features fit, and which do not

The sorting rule we use has four parts, and a feature has to pass all four. The answers are known in advance and can be listed. The decision repeats at volume, hundreds or thousands of times a day rather than ten. Nobody who receives the decision needs a written reason from the model itself. And the input is text, because Jev reads no images or audio [4].

Support routing passes: the queues are a fixed list, tickets arrive all day, the routing needs no explanation, and a ticket is text. Content moderation passes for the same reasons. So do document completeness checks, fraud signals that feed a score, re-ranking search results by a stated criterion, and validating a free-text form field against a rule. Drafting a reply fails the first test, because the answer is new text. Summarising fails it too. Negotiation fails the third test, because the other party will ask why. Anything that needs counting, arithmetic or date ordering fails on the model's own published weaknesses: TypeSafe's jaggedness page says Jev "does not count reliably", cannot reliably judge whether two numbers are near each other, and "reads dates as text, not as ordered quantities" [6].

Which features are System One tasks walks through the rule product type by product type, with the counter-examples that look like a fit and are not.

What a decision costs, with the arithmetic shown

Vendor price comparisons are the vendor's. We repeat them here with that label, and we show the arithmetic so you can rerun it at your own volume.

TypeSafe's headline benchmark, reported by MarkTechPost, has Jev finishing a workflow decision in 0.114 seconds for $0.000081 against GPT-5.6 Terra at 8.566 seconds for $0.013880, which TypeSafe presents as "193.6x faster and 444.6x cheaper". TypeSafe's own capabilities team wrote the workflows, and TypeSafe says it cannot prove the price is unsubsidised [7]. Multiply both per-decision prices by one million decisions a month and you get $81 against $13,880. Multiply them by 300, which is ten decisions a day for a month, and you get two cents against $4.16. That second pair is the reason the sorting rule includes volume. A feature that makes ten decisions a day saves nothing worth a migration.

Two third parties published their own figures. Openlayer's benchmark of its jevals library puts a Ragas evaluation on GPT-4.1-mini at $2.60 per 1,000 samples against $0.03 per 1,000 for one Jev request per sample, with Jev latency at a median of 244 milliseconds and a 95th percentile of 371 milliseconds, meaning 95 of every 100 requests came back within that time [8]. LangChain's test of five agent cases, run 100 times per judge, cost $0.34 with Jev and $28.17 with Claude Sonnet 4.6 for the full run [9]. Both are the publisher's own benchmark on the publisher's own tool, and five cases is a small set. The cost of a decision: a language model versus Jev does the full arithmetic at three volumes and says which figures come from whom.

The risk of being one week early

At writing, Jev is seven days old. There is one model version, jev-1.13.0, released on 15 September 2026, with two aliases that both point to it [2]. There is one vendor, one hosted API, and English as the primary training language [2]. TypeSafe has not disclosed the architecture [7], and, as noted above, says it cannot prove its price is unsubsidised. Each of these is a reason to design so the decision layer can be swapped, and you can build on it now.

The design that makes swapping cheap has three parts. The questions and the thresholds live in your own repository as plain text, owned by your team, so a new vendor or a language model can be asked the same things. A labelled test set, 100 to 200 cases with the answer a person gave, lives next to them, so any replacement can be measured before it is trusted. And a fallback path exists in code, to a language model or to rules or to a person, and is exercised on purpose, because TypeSafe's own API documentation lists a 529 "temporarily overloaded" error and tells clients to back off and retry [10]. A contract with a vendor should state which model version is pinned, how much notice a version change gets, and what happens to the price after the launch period. Early-access risk and vendor lock-in sets out the design and the contract clauses.

How to pilot it in two weeks

A pilot should be small enough to finish and strict enough to be trusted. The plan we would run, and we say plainly that this is a plan and not a result we have measured, fits in two weeks. Week one: pick one decision that passes the sorting rule, write the questions as your product would ask them, label 100 to 200 real cases by hand, and run the model in shadow mode, meaning it answers every case and nothing acts on its answers. Week two: compare the shadow answers against your current method on three numbers, agreement with the human labels, latency at the median and the 95th percentile, and cost per decision, then decide against cutoffs you wrote down before the run started.

The cutoffs are the part teams skip. A pilot with no stated pass mark ends in a meeting where the loudest opinion wins. Write the marks first: the agreement rate the feature needs, the latency the user will tolerate, the price per decision that makes the change worth doing. A two-week pilot for a decision model is the day-by-day version with what "done" means on each day, and it is printable.

What the specification has to say

A decision-model feature is specified differently from a generative one, because the interesting behaviour is at the thresholds. The specification must state the decision in one sentence, the allowed answers as a closed list, the threshold per consequence (TypeSafe's own guidance is that "different actions within the same system should be gated at different levels depending on the consequences", with 0.9 and above for acting automatically and below 0.5 for routing to a person [11]), the escalation path when confidence is low, the fallback when the API is down, what the audit record contains, who owns the labelled set, and the policy for model version changes.

Reveneau writes its eval suite from the specification before the code is written, and a decision-model feature is where that practice matters most, because every threshold in the spec becomes a check that runs on every change. Writing a specification for a decision-model feature gives the template and ties it to eval-driven development and to grading evals with Jev.

What to ask a vendor or a development partner

If a vendor's product, or a partner's proposal, says it uses Jev, the questions that separate a real implementation from a presentation are the same ones a diligence team would ask about any model dependency. Where is the labelled set. What is the agreement rate on it. What runs when confidence is low. What happens when the API is down. Which model version is pinned. What is logged per decision. Who owns the questions and thresholds. What did the last version change break.

We answer each of those for our own practice in Questions to ask a vendor or development partner that uses Jev, so you can see what a specific answer sounds like, and the list is printable. For an investor, the same questions belong in the management meeting; AI startup due diligence and its page on model dependency risk cover the wider set, and technical due diligence covers the codebase around it.

Governing a decision that comes with no reason

A Jev answer is a probability with no paragraph explaining it, because the model is "not trained to generate text" [6]. That changes what an audit record can contain and cannot contain. It can contain the state the model saw, the questions asked, every probability returned, the threshold applied, the action taken, the model version, and, if the case was escalated, the label the person gave. It cannot contain the model's reasoning, because there is none to record.

For most product decisions that record is enough, and it is more complete than the audit trail most language-model features keep today. Where a policy or a regulation requires a written reason for a decision that affects a person, the decision layer has to hand off, to a person or to a language model that writes the reason from the same state. We make no legal claim about which decisions those are; the financial, healthcare and regulated industry compliance guides say how to find out for your sector. Auditability when the model gives no written reason sets out the record and the hand-off rule.

Once the feature is live, six numbers tell you whether it is still working: agreement with a sample of human labels, escalation rate, the rate at which a person reverses the model's action, latency at the median and the 95th percentile, cost per decision, and drift in the shape of the probabilities over time. LangChain's test measured one thing worth adding to that list: across 100 repetitions of the same case, Jev's quality scores varied by a mean per-case variance of 0.0000149, against 92 to 913 times more variance from the three language models it was compared with [9]. A decision used as a gate, meaning a check that must pass before an action runs, needs to give the same answer to the same input, and repeat consistency is the measure of that. Measuring a decision model in production gives the metrics and a re-labelling schedule.

And sometimes the right move is back. The option set keeps changing, users start asking for a reason, agreement drops after a version change, the task turns out to need counting or dates, or English-only becomes a problem. A decision model is one tool among rules, language models and people, and a swappable design makes moving between them cheap. When to move back to a language model or to rules lists the signals.

Where Reveneau fits

We build products and agents, and all of our code is written by AI. Every change has to pass a large eval suite, written from the specification, before it is released. Where a product we build has a decision point that passes the sorting rule above, we use Jev at that point, with the questions and thresholds in the client's repository, a labelled set beside them, and a fallback in code.

We also use Jev inside our own process. This month we moved the grader in our eval suite from a language model to Jev, and the suite now runs ten times faster than it did, measured on our own suite against our previous grader. Checks with a deterministic answer, such as a test passing or a schema validating, never go to Jev. Jev grades the checks that used to need a language model as judge: whether a change matches a written acceptance criterion, whether a diff stays in scope, whether an agent's trace followed the plan. A grade below the threshold fails the change; a grade in the uncertain band goes to a person, whose label we keep to re-check the grader later. That is the practice. We publish no defect rate from it, because we have not measured one in a way we could show the working for.

We take responsibility for the whole project through production and after release. If you want to talk through whether a feature of yours fits, our AI development work is where that conversation starts.

Reading order

If you have one hour, read the three pages in the Decide group in order: the cost arithmetic, which features fit, and the early-access risk. If the answer is yes, the Plan group gives you the pilot and the specification. If someone else is building it, the Buy group has the vendor questions. Once it is live, the Govern group covers auditability, measurement, and when to move back.

The whole guide rests on one idea. The decision to use a decision model is smaller than it looks, if the design makes the model replaceable, and larger than it looks, if it does not.

Explore the guide

Decide

The cost of a decision: a language model vs Jev

One decision costs $0.000081 on Jev and $0.013880 on GPT-5.6 Terra, in TypeSafe's own benchmark, on workflows TypeSafe's own team wrote. At one million decisions a month that is $81 against $13,880. At ten decisions a day it is two cents against $4.16. This page works the arithmetic from every public figure we could find, says who published each one, and shows where the saving is real and where it is too small to justify moving anything.

Which features are System One tasks?

A feature is a System One task when four things are true: the answers are known in advance and can be listed, the decision repeats at volume, nobody needs a written reason from the model, and the input is text. Support routing, moderation, document checks, fraud signals, search re-ranking and form validation pass. Drafting, summarising, code generation and negotiation fail. Anything that needs counting, arithmetic or date ordering stays out on TypeSafe's own published weaknesses. This page applies the rule product type by product type.

Early-access risk and vendor lock-in

At writing, Jev is seven days old. There is one model version, jev-1.13.0, one vendor, one hosted API, English as the primary training language, and a price the vendor says it cannot prove is unsubsidised. All of it is a reason to design so the decision layer can be replaced in a week, and you can build on it now. The design has three parts: the questions and thresholds in your own repository, a labelled test set beside them, and a fallback path in code. The contract adds four clauses.

Plan

A two-week pilot for a decision model

This is the pilot we would run before putting a decision model into a product, written day by day with what done means on each day. Week one picks one decision, writes the questions, labels 100 to 200 real cases, and runs the model in shadow mode, meaning it answers every case and nothing acts on its answer. Week two compares those answers against the current method on agreement, latency and cost, and decides against cutoffs written before the run. It is a plan, stated plainly as one. We have not published a result from it.

Writing a specification for a decision-model feature

A specification for a decision-model feature has to state eight things: the decision in one sentence, the allowed answers as a closed list, a threshold per consequence, the escalation path when confidence is low, the fallback when the API is down, the fields in the audit record, the calibration set and its owner, and the policy for model version changes. Each of the eight becomes an automated check. Reveneau writes its eval suite from the specification before the code exists, and a decision-model feature is where that practice matters most, because the behaviour that matters lives at the thresholds.

Buy

Questions to ask a vendor or development partner that uses Jev

When a vendor's product or a partner's proposal says it uses Jev, eight questions separate a real implementation from a presentation: where is the labelled set, what is the agreement rate on it, what runs when confidence is low, what happens when the API is down, which model version is pinned, what is logged per decision, who owns the questions and thresholds, and what the last version change broke. A real answer to each is one sentence with a number, a file path or a named step. This page gives the eight, what a good answer sounds like, and Reveneau's own answers. It is printable.

Govern

Auditability when the model gives no written reason

A Jev answer is a probability with no paragraph explaining it, because the model is not trained to generate text. That removes one thing from the audit record and leaves everything else: the state the model saw, the questions it was asked, every probability it returned, the threshold applied, the action taken, the model version, and the human label if the case was escalated. For most product decisions that record is more complete than what a language-model feature keeps today. Where a policy or a regulation requires a written reason, the decision layer must hand off to a person or to a language model, and this page says how.

Measuring a decision model in production

Six numbers tell you whether a decision model is still doing its job: agreement with a fresh sample of human labels, the escalation rate, the rate at which a person reverses the model's action, latency at the median and the 95th percentile, cost per decision, and drift in the shape of the probabilities over time. Re-label a sample monthly and after every model version change. A seventh number, repeat consistency, matters for any decision used as a gate, and LangChain's five-case test is the only published measurement of it so far, which is why you measure it on your own cases.

When to move back to a language model or to rules

Five signals say a feature should move back from a decision model: the option set keeps changing, users need a reason, agreement drops after a version change and does not recover, the task turned out to need counting or dates, or English-only became a problem. A decision model is one tool among rules, language models and people, and none of the five is a failure of judgment; each is a task turning out to be a different shape than it looked. With the questions, thresholds and labelled set in your repository, the move is about a week of work. Without them it is a rebuild.

Common questions

What is a decision model, in business terms?

A decision model reads a piece of text and answers a fixed question with a probability, in under half a second, without writing anything. TypeSafe's Jev, released 15 September 2026, takes a state plus named questions and returns a typed answer per question. It fits features where the answers are a known list, the decision repeats at volume, and nobody needs a written reason from the model. It does not draft, summarise, count or order dates.

How do we decide whether a feature should use one?

Apply four tests and require all four to pass. The answers can be listed in advance. The decision repeats hundreds or thousands of times a day. Nobody needs the model's own written reason. The input is text. Support routing, moderation and document checks pass. Drafting, summarising, negotiation and anything needing counting or date ordering fail, the last three on TypeSafe's own published weaknesses for jev-1.13.

How much cheaper is Jev than a language model per decision?

Use the vendor's figures with the vendor's label. TypeSafe's benchmark, reported by MarkTechPost on 19 September 2026, puts one decision at $0.000081 against $0.013880 for GPT-5.6 Terra, on workflows TypeSafe's own team wrote. At one million decisions a month that is $81 against $13,880. At ten decisions a day it is two cents against $4.16, which is no reason to migrate anything.

Is it safe to build on a model that is one week old?

It is safe if the design does not depend on it. Keep the questions and thresholds as text in your own repository, keep a labelled set of 100 to 200 cases beside them, and keep a fallback to a language model, rules or a person in code and exercised. Then a version change, a price change or an outage costs you a swap, and TypeSafe's own API docs list a 529 overloaded error you should plan for.

What does a two-week pilot look like?

Week one: pick one decision that passes the four tests, write the questions, label 100 to 200 real cases by hand, and run the model in shadow mode so it answers and nothing acts. Week two: compare against your current method on agreement, latency at the median and 95th percentile, and cost per decision, then decide against cutoffs written before the run. This is the plan we would run; we have not published a result from it.

What must the specification for a decision-model feature contain?

Eight things: the decision in one sentence, the allowed answers as a closed list, a threshold per consequence, the escalation path when confidence is low, the fallback when the API is down, the fields in the audit record, the owner of the labelled set, and the policy for model version changes. TypeSafe's docs say to gate different actions at different confidence levels depending on consequences, so one threshold for the whole feature is a specification error.

What should we ask a vendor that says it uses Jev?

Eight questions, in order: where is the labelled set, what is the agreement rate on it, what runs when confidence is low, what happens when the API is down, which model version is pinned, what is logged per decision, who owns the questions and thresholds, and what the last version change broke. A vendor with a real implementation answers each in one sentence with a number or a file path. A vendor without one describes the model instead.

Can a decision with no written reason be audited?

Yes, with a record that stores what the model saw and did rather than why. Keep the state, the questions, every probability returned, the threshold applied, the action, the model version, and the human label if the case was escalated. Where a policy or regulation requires a written reason for a decision about a person, hand off to a person or a language model that writes the reason from the same state. Which decisions those are is a legal question for your sector.

What do we measure once it is live?

Six numbers, reviewed on a schedule: agreement with a fresh sample of human labels, escalation rate, the rate at which people reverse the model's action, latency at the median and 95th percentile, cost per decision, and drift in the probability distribution. Re-label a sample monthly and after every model version change. LangChain's five-case test found Jev's repeat variance at 0.0000149, and a gate needs that consistency, so measure it on your own cases.

When should we move back to a language model or to rules?

Move when any of five signals appears: the option set changes more than once a quarter, users or regulators ask for a reason, agreement drops after a model version change and does not recover after re-tuning the questions, the task turns out to need counting or date ordering, or a non-English market matters and the model's English-primary training shows. With questions, thresholds and a labelled set in your repository, the move is a week of work rather than a rebuild.

Why does Reveneau use Jev, and what does it claim from that?

We use Jev at decision points in the products and agents we build, and as the grader in our own eval suite, which now runs ten times faster than it did with a language model grading it, measured on our own suite. Deterministic checks never go to Jev. We claim no defect rate, no client count and no project history from this, because we have not measured any of those in a way we could show the working for.