BLUF: Most AI models we use today are designed to generate something. Jev is designed to decide something. You give it a situation and define the kinds of decisions you want back. It returns typed decisions with probabilities that software can use directly.
That sounds like a small difference. Architecturally, it is an interesting one.
Start with one example
Imagine a customer sends this message:
I was charged twice for my subscription.
If we send that message to a generative AI model, we might ask:
What should we do with this request?
The model could generate:
This appears to be a billing issue. The customer should be routed to the billing support team.
That answer is easy for a person to understand. But software does not really need the sentence.
It needs the decision:
Billing 96%
Account 2%
Technical 1%
Other 1%
→ BillingThat is the basic idea behind Jev, the first public System One Model from TypeSafe AI.
The simplest mental model
Generative AI
Situation
↓
Model
↓
Generate words
↓
"The customer should be routed to billing."
Jev
Situation
↓
Model
↓
Evaluate defined decisions
↓
Billing: 96%
↓
Software actsA large language model is excellent when the output should be language: an explanation, summary, email, answer, plan, or piece of code.
Jev is aimed at a different question:
What decision should the software make?
How does a Jev request work?
At a high level, a Jev request has two important pieces.
1. The state
The state is the information Jev should evaluate.
"I was charged twice for my subscription."2. The questions
You tell Jev what you want it to decide. The output space is defined rather than left open-ended.
TypeSafe currently exposes three main decision shapes:
- Choice — choose among defined options.
- Score — score something on an ordered scale.
- Noul — return a probability for a yes/no question.
For our support message, we might ask a Choice question:
State:
"I was charged twice for my subscription."
Question:
Which team should handle this?
Choices:
- Billing
- Account
- Technical
- OtherJev evaluates the state against those choices and returns a structured answer with probabilities and confidence information.
Why is that different from asking an LLM for JSON?
This is probably the most important question.
Today we can already ask an LLM:
Classify this request.
Return JSON:
{
"team": "billing"
}And modern LLM APIs can enforce structured outputs very well.
So the difference is not simply JSON versus text.
The deeper difference is what the model is being optimized to do.
LLM
optimized around generation
↓
can be constrained into a decision
Jev
built around decisions
↓
returns typed decisions and probabilitiesTypeSafe describes Jev as a model built specifically for fast, calibrated decisions inside software rather than for open-ended generation.
That makes Jev less like a chatbot that we force to behave like a classifier and more like a learned decision function that we call from code.
But isn't this just classification?
It certainly overlaps with classification.
A traditional classifier might already do this:
message
↓
classifier
↓
billingAnd for a stable, narrow problem with good labeled training data, a conventional classifier may be exactly what you need.
Jev's broader idea is to provide a general decision interface. Instead of building and training a separate classifier for every small decision, developers describe the current state and the decisions they need, and the model evaluates them.
So it helps to think of Jev as occupying space between two familiar approaches:
Hand-written rules
↓
Traditional task-specific classifiers
↓
General decision model such as Jev
↓
Generative LLMsThese are not replacements for one another. They solve different kinds of problems.
Where do the probabilities matter?
Suppose Jev returns:
Billing 96%
Account 2%
Technical 1%
Other 1%Your application might decide that anything above 90% can be routed automatically.
confidence >= 90%
↓
route automaticallyNow imagine the result is:
Billing 46%
Account 42%
Technical 7%
Other 5%The software can treat that uncertainty differently:
confidence too low
↓
do not automate
↓
send for reviewThis is one reason calibrated probabilities are useful. The model does not only make a choice; the surrounding application can decide how much authority to give that choice.
What does "calibrated" mean?
Calibration has a simple goal.
If a model makes many predictions at roughly 80% probability, we would like those predictions to be correct roughly 80% of the time on representative data.
That does not mean an individual 80% prediction is guaranteed to be correct. It means the probability should have useful statistical meaning across many decisions.
TypeSafe says Jev is trained using a method it calls Reinforcement Learning for Calibrated Decisions (RLCD).
The important distinction is that RLCD is TypeSafe's published description of its training approach. The company has not publicly released enough of the internal model architecture, training data, weights, or full training recipe for outsiders to independently reconstruct exactly how Jev works internally.
So we should separate two things:
What we can observe
-------------------
state + typed questions
↓
Jev
↓
typed decisions + probabilities
What is not fully public
------------------------
the complete internal architecture,
weights, data, and training recipeThat distinction matters whenever we explain a newly released AI system.
Why call it a "System One" model?
TypeSafe uses the term System One Model to describe this class of model.
The name borrows from the familiar distinction between fast, intuitive decisions and slower, deliberate reasoning.
The software analogy is straightforward:
System One style
fast decision
"Which route should I take?"
System Two style
deliberate reasoning
"Analyze this problem and explain the solution."Jev is intended for the first kind of work.
The term is TypeSafe's framing, not an established industry-standard model category yet. Jev was only introduced publicly in September 2026, so it is too early to know whether the terminology or architecture pattern will become widely adopted.
Where could this be useful?
Many software systems contain small decisions that are difficult to express as perfect rules:
Which team should receive this request?
Is this transaction suspicious?
Should this action require human review?
Which tool should this AI agent call?
Did the previous agent step succeed?
Should the agent retry?
How urgent is this request?Today those decisions might be implemented using rules, classifiers, or LLM calls.
A decision-focused model gives architects another option.
Jev does not replace the LLM
This is perhaps the easiest misconception to make.
If a customer asks:
Why was I charged twice, and how can I get my money back?
Jev is not meant to write the helpful explanation.
An architecture could instead look like this:
Customer message
↓
Decision model
↓
Which workflow?
↓
Billing workflow
↓
Retrieve account information
↓
LLM
↓
Helpful response to customerThe decision model chooses. The generative model communicates.
They can work together.
This becomes especially interesting for AI agents
An agent repeatedly makes decisions:
Understand goal
↓
Choose next action
↓
Call tool
↓
Inspect result
↓
Choose next action
↓
Call another tool
↓
FinishMany agent systems use an LLM for almost every box in that loop.
But not every box needs generated language.
A future agent architecture might separate the responsibilities:
┌── Search
│
User → LLM → Decision model ── Database
│
├── API
│
└── Human reviewThe LLM handles language and deeper reasoning. A decision model handles frequent structured choices. Ordinary code still controls permissions, thresholds, validation, and execution.
Where should you not use it?
A new model does not mean every decision needs AI.
If the rule is:
if accountBalance < 0:
showOverdraftWarning()Use code.
If you already have a highly accurate classifier for a stable problem, replacing it may provide little value.
If you need an explanation, conversation, long-form reasoning, code generation, or creative output, use a generative model.
The useful architectural question is:
Is this step asking AI to create something, reason deeply about something, or make a bounded decision?
A simple decision guide
| Problem | Natural starting point |
|---|---|
| Exact business rule | Code / rules engine |
| Stable classification with training data | Traditional classifier |
| Fuzzy, bounded decision from defined choices | Decision model |
| Open-ended reasoning or generation | LLM |
| Complex workflow | Often a combination |
The bigger architectural idea
For the last few years, it has been tempting to put one powerful LLM in the middle of everything:
Need to summarize? → LLM
Need to classify? → LLM
Need to route? → LLM
Need to score? → LLM
Need to decide? → LLM
Need to write? → LLMJev raises a useful architectural question:
Should one generative model really do every kind of intelligent work?
Perhaps not.
AI systems may increasingly look like ordinary software systems: different components optimized for different jobs.
Rules → deterministic decisions
Search → retrieve information
Decision AI → bounded judgments
LLMs → reasoning and generation
Code → control and executionThat idea is more important than Jev itself.
The mental model to keep
If you remember only one thing, remember this:
LLM:
"What should I say?"
Jev:
"Which decision should I make?"That is intentionally simplified, but it captures why Jev is interesting.
It is not another chatbot. It is an early example of a model designed around a different role: making fast, structured decisions that software can act on.
Whether System One models become a major category remains to be seen. But the architectural question they introduce is worth paying attention to: when software needs intelligence, generation is not always the job.