Lesson 1 · Why a decision model

About 25 minutes · no account needed until level 4, and the Playground is free to try

Automations are full of small decisions the problem

Goal: see why "ask an LLM and parse the answer" is the weak link in most workflows.

Every workflow that touches messy human input has a fork in it. Which team gets this ticket? Was that call a sales lead? Is this lead worth a human's afternoon? Should the agent book the appointment or ask first? For the last two years the default answer has been the same: write a prompt, send it to a large language model, and parse whatever text comes back.

Inputticket, transcript, form, e-mail
Prompt"Classify this as billing, technical or sales. Reply with JSON."
Textusually JSON, sometimes prose, sometimes both
Parserregex, retries, "please only output JSON"
if / elsethe workflow branches on a string

What goes wrong with that pipeline

  • No measure of doubt. The model writes "billing" whether it is 99% sure or 51% sure. The branch fires either way.
  • Format drift. The answer is text. A new model version, a long input or an odd character breaks the parser.
  • Latency and cost. A general model generates tokens one at a time. Seconds per decision add up in a voice agent or a 10,000-ticket backlog.
  • Persuasive by design. Chat models are tuned to sound agreeable and confident to a human reader, which is the opposite of what a machine needs from a classifier (TypeSafe AI primer).

These are not hypothetical. On 2026-09-17 the community's own benchmark ran 40 synthetic sales-call transcripts (English and German, two labels each) through Jev and two general-purpose models. The numbers below are copied from that brief; the method and every transcript are on the published benchmark page.

ModelMedian latencyBoth labels correctCost for 40 callsNotes
Jev 1.13 (TypeSafe)319 ms92.5%$0.001010 false bookings
GPT-5.6 Terra1,482 ms97.5%$0.046746× the cost of Jev
GPT-5.6 Luna1,804 ms95.0%≥ $0.005051 timeout

Read the table twice. Jev was not the most accurate model on that set. It was the fastest and the cheapest by a wide margin, and, as lesson 4 will show, the only one that handed back a number saying how sure it was. That number is the whole point of this course.

A model that decides instead of writes concept

Goal: be able to explain "System One model" in two sentences.

Jev is the flagship model of TypeSafe AI. TypeSafe calls it a System One model, after Daniel Kahneman's name for fast, intuitive judgement (docs: System One). The contract is narrow on purpose:

Statethe thing to judge: a string, a JSON object or an array of texts
Questionstyped, atomic, as many as needed, all evaluated in parallel
Answerstyped values plus calibrated probabilities. Never free text.
It does not generate.There is no completion, no chat, no summary. Jev cannot write a reply to the customer. It can tell you which reply your code should send.
It is calibrated.When Jev says 0.7, the docs claim that answer is right about 70% of the time across many such cases. That is what calibration means, and it is what makes thresholds meaningful.
Code owns the flow.Jev answers questions. Your workflow (Python, n8n, Make, a voice agent) decides what to do with the answers. Nothing in the model acts.

Why the training matters (one paragraph)

Chat models are tuned with RLHF, reinforcement learning from human feedback, which rewards answers people like. Reasoning models add RLVR, reinforcement learning with verifiable rewards, which rewards answers that pass a check. TypeSafe trains Jev with what it calls RLCD, reinforcement learning for calibrated decisions: the reward is for the probability being honest, not for the answer sounding good. The primer's argument is that human preference optimizes for a human reader and machine trustworthiness optimizes for a machine consumer, and the two pull in different directions (docs: AI primer).

Source: TypeSafe documentation, verified 2026-09-19. The training details are TypeSafe's own account; no independent audit exists yet.

Two-sentence version to remember: Jev reads text and answers typed questions about it with calibrated probabilities. It never writes text, so your code, not the model, decides what happens next.

Every question is one of three shapes concept + drill

Goal: pick the right primitive for a decision in under five seconds.

The docs call the question types primitives (docs: Questions). There are exactly three, and lesson 2 goes deep on each. For now, the shape and the return value:

ChoicePick one option from a closed set you define (2 to 255 options). Returns the winning choice, a probability for every option (they sum to 1) and a confidence.
"Which team?" · "What did the caller want?" · "Which language?"
ScorePlace the state on an ordered ladder of 2 to 10 levels you describe. Returns a score that can fall between levels, the probability of each level, and a confidence.
"How frustrated?" · "How severe?" · "How likely to churn?"
NoulA yes/no judgement. Returns one number, noul, between 0 and 1. No confidence field: the number is already the whole answer.
"Is it urgent?" · "Did they ask for a callback?" · "Is this spam?"

The choosing rule

Closed set of named outcomes → Choice. Ordered intensity or quality → Score. Single fact that is true or false → Noul. If a question needs "and" or "or" to state, it is two questions. Jev evaluates all questions in one request in parallel and independently, so asking more costs almost nothing (docs: multiple questions).

Drill: which primitive?

Eight decisions from real automations. Pick the shape. The explanation appears after each pick.

One request, three questions, real numbers hands-on

Goal: read a real Jev response line by line.

This is the request from the official quick start. A customer message is the state; three questions cover the three primitives. The "open in Playground" button loads it, prefilled, into TypeSafe's Playground, which needs a free account and no code.

{
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP.",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this",
      "criteria": {
        "billing": "Payment or subscription issues",
        "technical": "Bugs or integration problems",
        "sales": "Pricing or account questions"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated the customer appears",
      "criteria": ["Calm, just stating facts", "Frustrated but civil", "Very angry, strong language"]
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}

Before running it, predict: which department wins, and by how much? Then press the replay button. The response below was recorded from jev-1.13.0 on 2026-09-19; nothing is simulated except the button.

Simulated playground: the quick-start request

How to read it

  • department came back billing at 0.69 with technical at 0.31, and a confidence of 0.53. The model is torn, and it is right to be: a failing Stripe connection is both a payment matter and an integration bug. A chat model would have written "billing" and moved on. Jev handed over the doubt as a number.
  • frustration scored exactly 1 ("Frustrated but civil") with confidence 1. The three level descriptions were distinct enough that the model put all its weight on one.
  • is_urgent is 0.99. "3 days", "losing sales", "ASAP": an easy yes.
  • usage says 424 input tokens. At $0.042 per million input tokens that is about $0.000018 for the whole request. Output tokens are free (docs: Models).

The docs' own recorded run of the same request landed at 0.84 / 0.16 with confidence 0.60. Different day, same story: billing ahead, technical a real contender, moderate confidence. Lesson 4 turns that confidence number into a routing rule.

Three places a decision model belongs concept + exercise

Goal: name three decisions in your own workflows that Jev could own.

TypeSafe's "How to build" guide describes three architectures. They map neatly onto how this community already builds:

Traditional software + JevAn n8n or Make flow, a CRM webhook, a Python script. Code was already running the show; Jev replaces the brittle keyword rule or the "ask GPT and regex the answer" node.
Ticket triage · lead qualification · call outcome tagging
LLM agents + JevThe agent still talks. Jev sits beside it as a guardrail or router: is this request in scope, is the user trying to override instructions, which tool should run.
Voice agents · support bots · the "function calling" cookbook
AI-powered softwareNo LLM at all. Dozens of Jev questions fan out over each event and code assembles the result. Fast enough for real-time (about 100 ms per request per the docs).
Moderation · monitoring · smart-home command parsing

The use-case map lists the decision shapes Jev is built for: classification, detection, scoring, routing, extraction from a closed set, verification. What it is not built for: writing anything, arithmetic, date math, or reasoning across several documents (lesson 5 has the full list).

Exercise: three decisions from your own stack

Write down three forks in workflows you run or build. For each, one line in this form:

[event] → [question in plain words] → [what code does with each answer]

Example: call ended → did the caller want a quote? → yes: create CRM deal; no: archive; unsure: human review queue

Keep the list. Lesson 3 turns these lines into real questions, and lesson 6 wires one of them into an HTTP node.

Quiz, then carry one idea forward quiz

Goal: prove the mental model survived the lesson.

1. What does Jev return for a question, in every case?

Typed values plus probabilities, never text. That is the whole contract of a System One model. Your code decides what to do with the numbers.

2. A workflow must decide whether a caller is an existing customer. Which primitive?

One fact, true or false: a Noul. A two-option Choice would also work, but the docs note Noul and Choice are not guaranteed to agree, so pick the shape that matches the question.

3. In the quick-start run, department came back 0.69 billing versus 0.31 technical. What is the right reading?

A failing payment integration really is both. The split is information, not noise. Lesson 4 shows how to route on it instead of ignoring it.

4. Which of these is Jev NOT designed to do?

No generation, ever. Pair Jev with an LLM when text has to be written, and let Jev decide whether and which.

Ship it

Create a free account at console.typesafe.ai, open the quick-start request from level 4 in the Playground, and change the customer message to something from your own inbox. Watch the department split move. That is the entire feedback loop of this course: change the state or the question, read the numbers, repeat.

Primary source for this lesson: docs.typesafe.ai/introduction (five minutes) and the AI primer (fifteen minutes, worth it).