--- title: "System One AI: don't burn 800ms just to get one routing keyword" description: "Explore System One AI with TypeSafe Jev: replace slow LLMs with Typed Decisions, probability distributions and the three primitives Choice, Score and Noul." pubDate: 2026-09-22 updatedDate: 2026-09-25 author: tusgino tags: [ai-engineering, architecture, automation] cover: /images/covers/system-one-typed-decisions.svg coverAlt: "System One AI architecture diagram and Typed Decisions with the Jev model" lang: en faq: - q: How is a System One model different from a traditional LLM? a: "A traditional LLM (System Two) generates free text token by token, costs 500-1500ms and easily breaks the JSON format. A System One model (like Jev) does not generate text: it estimates probabilities and returns a concrete data type directly (Choice, Score, Noul). The Playground at the end of this post measures the real latency of each call." - q: Why is Noul not an ordinary Boolean type? a: A Boolean only has true or false. Noul returns a calibrated probability P(true) from 0 to 1, which lets engineers set a Confidence Threshold that matches the risk of each business problem. - q: How does Speculative Fan-out work? a: It lets you send one input state into the model and query many primitives at the same time (Choice, Score, Noul) in a single API call. Jev loads the state once, then evaluates every question in parallel on the same context, so the answers always stay consistent with each other. - q: When should you still use an LLM instead of a System One model? a: "When a task needs text generation, multi-step reasoning or an explanation of the reason, an LLM is still the right choice. System One only replaces the LLM where the code only needs a label, a score or a probability — that is, branching decisions." --- Do not use a 70B text-generating LLM just to run one `if-else` statement. A System One model returns Typed Decisions with a calibrated probability distribution, and does not generate a single text token. ## The 800ms paradox of the software engineer Look at a familiar piece of customer-message routing code in today's agent systems: ```ts title="legacy-router.ts" // The naive way we still use every day const response = await openai.chat.completions.create({ model: "gpt-4o", response_format: { type: "json_object" }, messages: [ { role: "system", content: "Classify this message into 1 of 2 groups: 'refund' or 'shipping'." }, { role: "user", content: customerMessage } ] }); const route = JSON.parse(response.choices[0].message.content).intent; ``` From the point of view of an infrastructure and automation engineer, the code above is **a complete waste**: 1. **Terrible latency:** You spend **800ms to 1.5 seconds** only to get back a string of 6 characters (`"refund"`). 2. **Unreasonable token cost:** You force a GPU to run autoregressive decoding and generate dozens of JSON tokens with heavy syntax. 3. **Schema Fragility:** Even with Structured Outputs, a text-generating model still has some chance of producing a strange string or a timeout. 4. **Uncalibrated Guess:** The JSON string tells you the model chose `"refund"`, but **it does not tell you whether the model is 99% sure or just flipping a coin at 51% vs 49%**. That is why we need a shift in thinking: the **System One Model**. --- ## Core concept: what is a System One Model? **A System One Model is an AI model that does not generate text.** It runs a single inference pass and then returns a decision that already has a data type (Typed Decision) with a calibrated probability distribution, instead of decoding token by token like an LLM. The name comes from psychology. The economist Daniel Kahneman once split human thinking into two mechanisms in *Thinking, Fast and Slow*: - **System Two:** Slow, step-by-step logical reasoning, uses a lot of energy (similar to reasoning models and LLMs that generate long text). - **System One:** Lightning fast, intuitive reflex, recognises patterns in an instant based on accumulated probability. ```diagram type: flowchart title: System One model processing flow desc: Five steps from Input Request through Vector Logits to Gating and safe execution nodes: - id: input label: Input Request sub: User prompt / Chat / API kind: input - id: sys1 label: System One Engine sub: Single Pass Vector Logits focal: true - id: typed label: Typed Decision sub: Choice, Score or Noul focal: true - id: gate label: Threshold Gating sub: Check Confidence & Risk kind: security - id: exec label: Safe Automation sub: Run automatically or hand off to a human edges: - [input, sys1] - [sys1, typed] - [typed, gate] - [gate, exec] ``` In September 2026, **TypeSafe AI** (founded by Diogo Almeida — a former OpenAI researcher and co-author of the RLHF technique) announced **Jev**, the first model built only for System One (see the [official primitive documentation](https://docs.typesafe.ai/primitives)). The list price is \$42/Btok, equal to **\$0.042 per million input tokens**, and **output tokens are free** — Jev 1.13 even ships with open weights. The System One philosophy is firm: **AI does not generate text (No Text Generation). AI only makes decisions that have a data type (Typed Decisions) with a calibrated probability distribution (Calibrated Distribution).**
  • Generates tokens one by one (800ms - 2000ms).
  • Returns text/JSON: to get the decision, your code must parse it and trust the format.
  • Bills both input and output tokens — the generated JSON is billed too.
  • Easily "guesses" when the question is vague.
  • Infers directly through an embedding and a classification head.
  • Returns a static data type plus a probability distribution for each option.
  • Bills input tokens only; output tokens are free.
  • Lets you measure uncertainty (Entropy) so you can stop safely.
 --- ## The three core primitives of a Typed Decision These three primitives are the whole grammar of System One: `Choice` picks a label, `Score` measures a level, `Noul` answers Yes/No with a probability. ```diagram type: layers title: Speculative Fan-out architecture desc: Four layers processed in parallel in a single inference pass of the System One model nodes: - id: state label: 1. Input State (context) sub: Customer complaint / Chat log / Shell command kind: input - id: jev label: 2. Jev Engine (Single-pass) sub: One single matrix inference pass focal: true - id: fanout label: 3. Parallel Typed Decisions sub: Choice (intent) · Score (level) · Noul (phone call) focal: true - id: pipeline label: 4. Gating & Decision Pipeline sub: Safe automation or hand off to a human kind: security edges: - [state, jev] - [jev, fanout] - [fanout, pipeline] ``` ### 1. Choice — Multi-class classification and distribution shape `Choice` picks 1 label from a fixed list (up to 255 labels). The key point: it does not return only the winning label, it returns **the whole shape of the probability distribution (Distribution Shape)**. If the result is `[A: 95%, B: 5%]`, the model is extremely sure. But if the result is `[A: 52%, B: 46%]`, even though $A > B$, choosing $A$ automatically is a production bug waiting to happen — the chaos (Entropy) is too high to trust. Comparing two probability distribution shapes of the Choice primitive: [A: 95%, B: 5%] has low entropy so it can be automated, while [A: 52%, B: 46%] has high entropy so it must go to a human ### 2. Score — Ordinal scale Instead of discrete classification, `Score` rates a level on a quantitative scale (usually from 0.0 to 1.0, or a rubric from 1 to 5 stars). The returned value is the probability-weighted average of the whole scale: - Measure the severity of an incident (Severity: `0.92`). - Score how harmful or risky a tool command is (Risk Score: `0.85`). ### 3. Noul — Bernoulli probability from 0 to 1 `Noul` (a playful shortening of *Bernoulli*) answers Yes/No questions. **Noul is not a rough `true/false` boolean type**. Noul returns a real number: $$ P(\text{true}) \in [0.0, 1.0] $$ Why not let the AI return a boolean? Because **the decision threshold (Confidence Threshold) is the right of the system engineer**, not of the model! - For a task that sends a suggestion email: $P(\text{true}) \ge 0.60$ is enough to allow the send. - For a task that deducts money from a wallet: you must require $P(\text{true}) \ge 0.98$. Do not just read the theory, scroll down to the Playground below to test the Confidence Threshold and watch the Circuit Breaker work in real time. There you can also edit the PRIMITIVE SPEC itself: add or remove `Choice` options together with their descriptions, edit each rubric level of `Score`, and edit all three questions of the fan-out round in section 03 — `Score` for a level, `Choice` for routing, `Noul` for a Yes/No question — then see how the probability distribution changes. Descriptions are not decoration: TypeSafe sends both the name and the description to the model, so this is exactly where you teach the model to tell two similar options apart. The input field is capped at 280 characters, because every character you send is an input token you have to pay for. --- ## The practice area: hands-on labs Below are 3 real scenarios that simulate how to fit a System One Model into a modern software architecture: --- ## Two architecture patterns you must remember From the 3 hands-on labs above, two architecture lessons shape the whole way we build the next generation of agents: ### 1. Tool Risk Gating (a safety gate for AI agents) When you give an agent the right to run dangerous commands (Shell script, Database mutation, API that calls outside), relying on a "be careful" prompt is meaningless. Instead, before every tool run, we use the `Score` primitive to measure a Risk Score. If the command passes the safe threshold ($Score > 0.35$), the system automatically blocks it (Intercept) and asks for an approval signature from a human (Human-in-the-loop). ```ts title="tool-guard.ts" const risk = await jev.score(toolCall.command, { rubric: "0.0: Read-only safe -> 1.0: Irreversible destruction" }); if (risk > 0.35) { await requestHumanApproval({ command: toolCall.command, riskScore: risk }); return; } await sandbox.execute(toolCall.command); ``` ### 2. Speculative Fan-out (grouping reasoning branches) Instead of making 3 API calls to the LLM one after another: 1. Ask about customer sentiment? (800ms) 2. Ask the main intent? (800ms) 3. Is an urgent phone call needed? (800ms) System One lets you group all 3 questions into **one single API call** (`POST /v1/systemone`). Jev loads `state` once, then evaluates every question in parallel on that same context, so all 3 decisions always stay consistent with each other — something that 3 sequential calls cannot guarantee. --- ## Steps to deploy in your own project Check the flows in your codebase that use an LLM only to get a boolean or an enum back. Replace long-winded prompts with standard `Choice`, `Score` and `Noul` definitions. Set the confidence threshold and the Circuit Breaker mechanism that hands the case back to a human when the model is unsure. Measure P95 latency and token cost on your own data. Do not trust a generic benchmark number: long context and complex questions both change the latency. A decision that has a data type is the decision with the fewest surprises. Never let AI guess when you cannot control the probability distribution. - Stop forcing an LLM to generate JSON text only to serve `if-else` branching logic. - A System One Model (Jev) returns Typed Decisions with a probability distribution, generates no text and does not bill output tokens. - The set of 3 primitives Choice, Score and Noul lets you control risk thanks to a calibrated probability distribution. - Always set a Confidence Threshold to trigger the Circuit Breaker when uncertainty (Entropy) passes the safe limit.