What is Jev? A Simple Primer on AI That Makes Decisions

Most of the AI we encounter today is designed to generate things: text, images, code, answers. Jev, a new model from former OpenAI researcher Diogo Almeida, is built around a different idea.

Instead of asking AI to produce an open-ended response, you ask it to make a small, well-defined judgment: Is this suspicious? Which category does this belong to? How risky is this?

It returns a structured answer with an attached probability.

That sounds simple, but it points to a different way of putting AI inside software.

This is a short, nontechnical primer on what Jev is, how it works, and why the idea is interesting.

The basic idea

The simplest way to understand Jev is this:

Jev is an AI model designed to make small, fast, structured decisions inside software.

Instead of asking it to produce an open-ended response, you give it the current state of a situation and a specific question to answer.

Jev then returns a structured decision with a probability attached.

For example, imagine a software system looking at an expense claim.

It already knows a few facts:

• the expense is £127
• the category is a meal
• manager approval has not yet been given

The system can then ask Jev a narrow question:

Does this expense need manager approval?

Jev might answer:

• YES: 0.97
• NO: 0.03

Your software can then decide what to do:

if P(YES) > 0.90:
    send_to_manager()

The important point is that Jev makes the judgment, but your software still decides what that judgment means.

That is the main idea.

TypeSafe calls Jev its first System One Model, designed for fast, bounded judgments that software can act on directly.

Think of Jev as a smart decision function

Conceptually imagine a normal function:

should_escalate(ticket)

Ordinary code might contain rules like:

if ticket.value > 10000:
    return true

But reality is rarely that clear.

You might instead need to answer questions like:

Does this customer actually sound upset?

Does this transaction look suspicious?

Which team is best placed to handle this?

How serious is this incident?

Those are fuzzy judgments.

There usually isn't a neat value sitting in a database that says:

customer_is_actually_upset = true

Jev wraps that kind of fuzzy judgment in something that feels more like a software function.

State goes in. A typed answer with a probability comes out.

In other words, it lets software ask questions that are difficult to express as simple hard-coded rules.

Jev basically gives you three kinds of primitives

The current TypeSafe API exposes three basic question shapes:

• Yes / No
• Choice
• Score

In plain English, that means Jev can answer:

• Is something true?
• Which option fits best?
• How strongly does something apply?

You can think of them as:

Noul    → Is X true?

Choice  → Which X?

Score   → How much X?

The interesting part is that you can combine these small judgments to create larger workflows.

For example, a system might first ask:

Does this request look fraudulent?

If not, it might then ask:

What kind of request is this?

And finally:

How urgent is it?

Jev provides the fuzzy judgments.

Your code defines the workflow.

A useful way to think about the division of labour is:

Jev makes the judgment. Your code decides what to do with it.

A useful example: customer support

Imagine a customer says:

"I cancelled two weeks ago and you've charged me again. I'm really annoyed and I'm thinking of leaving."

A customer support system could make several small judgments about that message.

It might ask:

• Is fraud involved?
• What is the main issue?
• How likely is this customer to leave?

Each of those is a separate, narrow judgment.

Together, they can guide what happens next.

Perhaps Jev decides:

• fraud is unlikely
• the main issue is billing
• churn risk is high

The system can then route the message to a human retention team.

What's interesting is that you can see precisely where intelligence exists in the workflow.

You're not saying:

"AI, deal with this customer."

You're saying:

I know how this business process works.

I just need intelligence at these specific decision points.

That is a very different engineering philosophy.

Turning fuzzy judgments into software decisions

Traditional software is great when the rule is precise:

age >= 18

balance < 0

country == "UK"

These are easy because the facts already exist and the rule is explicit.

But some rules look more like:

Does this seem suspicious?

Is this document actually relevant?

Does this response adequately answer the question?

Is this request unusually risky?

You can't easily write:

if suspiciousness == true:

because "suspiciousness" isn't sitting in your database.

Jev effectively lets you create something resembling:

suspiciousness = jev(state)

and get something like:

0.93

Your software can then turn that judgment into policy:

if suspiciousness > 0.90:
    block_transaction()

elif suspiciousness > 0.60:
    send_for_review()

else:
    continue()

Another way to think about it is that Jev turns a messy real-world judgment into something ordinary software can act on.

It takes an ambiguous situation, produces a probability, and lets code use thresholds to decide whether to proceed, review, or stop.

That is probably the most useful mental model.

Jev is deliberately bounded

One interesting thing about Jev is that you define the possible answers upfront.

Imagine you're building a ticket-routing system.

You might decide that every ticket must go to one of four places:

• Billing
• Technical
• Sales
• Fraud

Jev's job is to judge which of those options fits best.

It isn't allowed to suddenly decide:

"Actually, create a new department."

The space of possible answers already exists.

That constraint is intentional.

TypeSafe describes Jev outputs as typed, meaning the surrounding software knows the structure and possible forms of the answer in advance.

So rather than giving the model complete freedom over what happens next, the software defines the boundaries first.

Software defines the world. Jev makes judgments inside that world.

This makes the model less open-ended, but for many software systems that may actually be a useful property.

Why probabilities matter

Suppose Jev answers:

Fraud?

YES: 0.51
NO:  0.49

That tells you something important.

The system isn't very confident.

So perhaps your software says:

confidence < 0.70

means:

HUMAN REVIEW

But if Jev returns:

YES: 0.995
NO:  0.005

you might be comfortable allowing an automatic action.

The confidence score therefore isn't just extra information.

It can become part of the control logic.

For example:

• low confidence → human review
• medium confidence → another check
• high confidence → automatic action

That creates a useful separation between judgment and policy.

Jev produces the probability.

Your software decides what level of confidence is good enough.

The bigger architectural idea

Most software is built around a fairly simple idea:

input goes in, code applies rules, output comes out.

That works extremely well when the world is clean and predictable but ordinary code struggles when the rule depends on interpretation.

• Was the customer genuinely upset?
• Does this document seem relevant?
• Does this transaction look suspicious?

Jev introduces another building block.

Instead of forcing everything into deterministic rules, software can combine:

• deterministic logic for exact rules
• judgment logic for fuzzy decisions

That's the interesting idea.

It's not:

"replace the application with AI."

but:

put machine judgment exactly where deterministic logic isn't enough.

What might this look like in a real workflow?

Imagine an invoice-processing system. Some steps are straightforward. The system can calculate totals using normal code. It can check whether an invoice has already been paid using a database lookup.

But other steps involve judgment.

• Is this a valid invoice?
• Do the fraud indicators look suspicious?
• Does the vendor information seem correct?

A workflow might therefore alternate between ordinary code and Jev judgments.

Notice what's happening.

The intelligence isn't one enormous black box instead it's scattered through the workflow:

CODE
JEV
CODE
JEV
CODE

Each component does the thing it is good at. The application still owns the overall process. Jev is inserted where fuzzy judgment is needed.

TypeSafe's published workflow evaluations use this general philosophy: break a business process into programmatic rules and narrow intelligent judgments, then compose them into a larger workflow.

A simple mental model to remember

Strip everything else away, and the contrast is fairly simple.

Ordinary code works well when you already have:

• clear facts
• clear rules
• a deterministic answer

Jev becomes useful when you instead have:

• messy facts
• an ambiguous judgment
• a probability-backed answer

In practice, the two work best together.

Software handles the overall workflow and Jev is called at the specific points where judgment is needed.

Or in one sentence:

Jev turns fuzzy judgments into typed, probability-backed values that ordinary software can use.

That is probably the cleanest definition.