Blog - How Jev works

A language model writes an answer. Jev does not.

It is TypeSafe’s flagship System One model. You send a state — text, a JSON object, or an array of text — and the questions you define in code. It returns typed answers and probabilities. It does not draft the email, explain its reasoning, or generate code.

The name comes from Daniel Kahneman: System 1 is a fast judgment, System 2 is slow, deliberate reasoning. Jev is built for the first. One question should be the kind of call a person who knows the domain makes in a second, given the right context.

How it differs from an LLM

It understands natural language, the way a chat model does. That is where the similarity stops.

• The answer stays inside the options you supplied. You do not have to recover a decision from a paragraph.
• Probabilities are trained so that, across a set of predictions, they reflect uncertainty. Calibration does not guarantee that any single answer is correct.
• Input is text only for now. Images, audio, and video are not supported.

What you send

One call: the state, a model name (the docs usually use jev-latest), and a map of questions. Each question has its own id, a type, and instructions. The id is for your code. The model never sees it, so the full question has to live in instructions.

Three shapes of answer

Choice fits when the options have no order: billing, technical, account. Add an “other” when the list might not cover the input.

Score fits when you describe the levels yourself: calm, frustrated, furious. A result of 1.4 means “between the first and second level, closer to the second”, not a school grade.

Noul is a clean yes or no. 0.95 is a strong yes, 0.05 a strong no, and around 0.5 is a tie. There is no separate confidence field — the number is the confidence. 0.5 does not mean “a medium skill level”. If you want to measure a level, use a Score with named steps.

Many questions at once

Questions in one request see the same state, run in parallel, and do not peek at each other’s answers. Adding another barely changes the latency. You pay for the question’s tokens, not for reading the whole state again.

So ask about each factor on its own and combine the result in code, instead of asking the model to “analyze this and decide”. Ticket priority can be a weighted mix of three Scores: how severe the bug is, how frustrated the customer is, and how much an engineer has to start from. You change the weights in code, without rewriting the prompt.

A second call is worth it only when you cannot build the next state without the first answer — for example you have to fetch more data, or the next Choice’s options depend on the previous one.

What it looks like on a ticket

State: “I was charged twice for order A-104. Please refund the duplicate.” Next to it, a policy: duplicate charges are eligible for a refund.

The code does not parse a sentence. It compares numbers and labels. Low confidence, or a Noul near 0.5, is the signal to hand the case to a person or a slower model instead of acting automatically.

When the state is JSON with several parts, point at a path in instructions, for example `ticket.messages[0].text`. The model then knows which piece to judge.

When it is the wrong model

Jev will not write the reply to the customer, and it will not take “analyze the whole thing and propose a plan”. That sentence has to be split into small judgments, or given to a model that generates text.

It cannot see a screenshot. It will not explain why it decided. If a person needs a rationale, you assemble it yourself from the answers you got.

Why it shows up in a product

Use it where the decision should land in an if, a threshold, or a queue: routing a ticket, detecting a refund request, flagging urgency, scoring tone. Keep the LLM for the conversation and for work that actually needs longer reasoning. Jev is the fast, bounded judgment you can build ordinary code on.