Jev / System One
structured
decisions
out
A deep dive from the chatbot era into the decision era

Jev is not a smaller chatbot.
It is a decision engine.

What happens when an AI model stops generating prose and starts returning the typed, probabilistic judgements that software actually needs?

Based on Senko Rašić’s analysisSeptember 202619 slides
Read with healthy scepticism: the article calls its model explanation a reasonable guess.01 / 19
Start here · plain-English summary

LLMs write. Jev judges.

Jev takes messy state, asks several tightly defined questions, and returns typed answers such as a choice, a score, or the probability that a statement is true.

fastNo token-by-token prose generation. Questions can be evaluated in parallel.
typedOutputs are constrained to the structure you define, so your code does not need to parse a paragraph.
composableUse confidence and probabilities to branch, route, escalate, or combine judgements in ordinary code.

Best mental model: a frontier-intelligence function call — unstructured state in, typed probabilistic decisions out.

Sources: article + TypeSafe introduction02 / 19
Before the deep dive

Use it where the answer has a shape.

Choice

Pick one path

Route a support ticket to billing, technical, or sales. The options are declared before the model answers.

Score

Place it on a scale

Estimate frustration, risk, severity, or fit against a rubric with named levels.

Noul

Is this true?

Return a 0–1 probability for a focused yes/no judgement, such as “does this message request a refund?”

The name “Noul” is TypeSafe’s primitive for a probability that a statement is true. It is not a general-purpose answer generator.

Source: TypeSafe primitives documentation03 / 19
01 / The idea

Why this is different

The interesting move is not “make an LLM cheaper”. It is “stop forcing a text generator to behave like a typed decision API”.

From prose generation to software-native decisions04 / 19
The core distinction

Strings are powerful. They are also a poor interface.

Typical LLM workflow
  • Generate a sequence of tokens, one after another.
  • Ask for JSON or a label inside the generated text.
  • Parse, validate, and handle refusals or malformed output.
  • Confidence is usually an extra request, not a native signal.
Jev / System One workflow
  • Ingest state and evaluate typed questions.
  • Return values inside a structure declared up front.
  • Receive probability distributions for Choice and Score.
  • Compose the results with deterministic application code.

Design implication: put language understanding at the fuzzy edge, then let ordinary code own the workflow, policy, thresholds, and side effects.

Source: TypeSafe’s “Frontiers, Old and New” comparison05 / 19
A useful approximation, not a published paper

Think “modern BERT with instruction-following”.

Senko Rašić’s explanation is explicitly a simplification. The useful comparison is with classification models such as BERT: they are fast and cheap for defined judgements, but traditionally need task-specific fine-tuning.

StateText, records, conversation, game state, policy.
→
Typed questionsChoice, Score, or Noul. Each question has its own instructions.
→
Structured answersValues, probabilities, and confidence where available.

The article notes that Jev’s model size is not public. Avoid treating any parameter estimate as fact.

Source: article, “How it (probably) works”06 / 19
The performance idea

One state. Many independent judgements. One call.

Instead of making a workflow wait for one classifier, then another, Jev evaluates questions independently against the same state. You can ask for routing, urgency, and frustration together.

One ticket“The Stripe integration keeps failing. I’m losing sales.”
→
Fan-out
departmentfrustrationurgent?
→
BranchRoute, prioritise, and escalate with code.

Key pattern: ask every question your code might need, even if some answers will be ignored for this input. The API is designed for speculative fan-out.

Sources: article + TypeSafe primitives documentation07 / 19
What you gain

Less parsing. Less latency. More explicit control.

Automation

Smart if-statements

Use a model where hand-written rules are brittle but a full agent would be overkill.

Operations

High-volume triage

Classify, score, and route tickets, documents, or product feedback in a single request.

Safety

Verify the fuzzy edge

Score prompts, traces, outputs, jailbreak attempts, or policy fit before the next action.

Real time

Latency-sensitive UX

Make quick decisions inside an application without waiting for a prose response.

Games

Reactive state machines

Score player or world state, then let deterministic rules select the next NPC or crisis branch.

Data

Map-reduce at scale

Turn large collections of unstructured records into structured features and signals.

Use cases are synthesis; TypeSafe lists analogous categories in its announcement.08 / 19
02 / Evidence & limits

Fast is useful.
Evidence is better.

Jev looks compelling for the right task. The right question is not “is it better than an LLM?” but “does it fit this decision surface, with acceptable error and uncertainty?”

Interpret benchmark claims in context09 / 19
The article’s hands-on test

Nearly the same accuracy, without fine-tuning.

On 3,000 Croatian-language texts, the author reports 97.1% for zero-shot Jev versus 97.6% for a fine-tuned local BERT. The difference is small, and the author says many disagreements were label-quality issues.

Jev, zero-shot
97.1%
Fine-tuned BERT
97.6%
96%97%98%

Important: this is one author’s random sample and one task, not a universal benchmark. It supports “test the fit”, not “Jev always wins”.

Source: article, “Jev vs BERT”10 / 19
The claim needs a precise definition

Type-safe is not the same as correct.

What it can rule out: output outside the structure you specified. No invented JSON key, no free-form prose where a Choice was required.

What it cannot rule out: a wrong classification, a biased rubric, missing context, or a confident but mistaken judgement.

Think in two axes

Schema validityDid the answer fit the allowed type and options?
↓
Task validityWas the judgement right for your data, policy, and stakes?
Sources: article + TypeSafe introduction; wording intentionally distinguishes type errors from task errors.11 / 19
Reliability is an architecture question

Confidence should change what the system does next.

LowDo not act. Escalate, clarify, or fall back.
MediumConfirm, gather more context, or review.
HighAutomate low-risk actions; keep high-risk confirmation.

Risk sets the threshold

Showing the wrong screen is recoverable. Approving a transfer is not. Use different confidence gates for each action.

if confidence < 0.5:
route_to_human()

if high_stakes and confidence < 0.9:
ask_for_confirmation()

Prompt injection: the article reports informal tests suggesting Jev may resist some attacks better because state and instructions are separate. Treat that as a hypothesis until you run adversarial evaluations on your own workflow.

Sources: article + TypeSafe confidence documentation12 / 19
03 / Build it

Start with a question.
End with a workflow.

The implementation is small. The product work is deciding what the model is allowed to judge, what evidence it sees, and what the surrounding code does with uncertainty.

A step-by-step implementation guide13 / 19
A practical build sequence

Four moves from idea to safe prototype.

01
Define the state

Pass the smallest useful record: text, metadata, policy, or structured context.

02
Split judgements

Ask one focused question per dimension. Avoid “analyse everything and decide”.

03
Batch the call

Mix Choice, Score, and Noul in one request when they share the same state.

04
Own the branch

Use probabilities and confidence in application code. Gate side effects by risk.

Rule of thumb: if a judgement needs extended reasoning, decompose it into smaller factors and compose the result in code.

Source: TypeSafe primitives and confidence documentation14 / 19
Official SDK shape, simplified for teaching

Ask three questions in one request.

python · typed decisions
# pip install typesafe-sdk
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()
response = client.system_one(
    state=ticket,
    questions={
        "department": Choice(
            instructions="Which team should handle this?",
            criteria={"billing": "Payment or subscription issues",
                      "technical": "Bugs or integration problems",
                      "sales": "Pricing or account questions"}),
        "frustration": Score(
            instructions="How frustrated does the customer appear?",
            criteria=["Calm", "Frustrated", "Very angry"]),
        "is_urgent": Noul(
            instructions="Does the message convey urgency?"),
    },
)

The article’s example uses the same three primitive types. The current quick start also documents the Python SDK, API route, and response shape.

Source: TypeSafe quick start + article code example15 / 19
Do not stop at the API call

Make the surrounding code boring.

JevReturns Choice, Score, Noul, probabilities, and confidence.
→
Policy layerApply thresholds, weighting, permissions, and business rules.
→
Side effectRoute, notify, retrieve, ask for confirmation, or do nothing.

Good decomposition

“How severe is the bug?”
“How frustrated is the customer?”
“How complete is the reproduction?”

Bad decomposition

“Read this ticket, reason about everything, and decide what the company should do.”

Architecture payoff: when priorities change, change weights and thresholds in code instead of rewriting one giant prompt.

Source: TypeSafe primitives documentation, composite scoring guidance16 / 19
Worked design example

Game NPCs are a good fit for fuzzy edges.

Imagine a nemesis system that needs fast, explainable signals rather than a conversational monologue. Jev can score state; deterministic code can own the actual game rules.

World statePlayer health, faction reputation, recent choices, crisis timer.
→
Questions
player vulnerable?revenge likely?crisis urgent?
→
Game logicChoose ambush, retreat, negotiate, or escalate using thresholds and cooldowns.

Why this is interesting: the AI supplies a fast judgement about a rich state; the game remains testable because the state machine still owns the action.

Worked example is an application design inference, not a TypeSafe product claim.17 / 19
A decision checklist

Use Jev when the decision surface is narrow.

✓
There is a small answer space.Choice, ordered score, or probability of a defined statement.
✓
Latency or cost matters.You are making many decisions, or the UX cannot wait for prose.
✓
You can define the state.The model gets the relevant evidence without needing a long discovery phase.
✓
You can test the rubric.You have examples, labels, reviewers, or a golden set to measure task validity.
✓
You want code to own policy.Thresholds, weights, permissions, and side effects stay inspectable.
✓
You do not need prose generation.If users need a nuanced explanation, pair the decision model with a generator.

Do not use it as a universal LLM replacement. If the task is open-ended reasoning, creative generation, or evidence synthesis, use a model and workflow designed for that job.

Recommendation synthesised from the article and TypeSafe’s public docs.18 / 19
Keep exploring

Jev’s real promise is not magic.
It is a better interface.

The opportunity is to put fast, calibrated judgements exactly where software needs them — then keep the system honest with tests, thresholds, and human escalation.

Senko Rašić · Analyzing Jev, a new AI modelarticle ↗ TypeSafe · Introducing System One Models & Jevprimary ↗ TypeSafe · Quick startdocs ↗ TypeSafe · Primitives / questionsdocs ↗ TypeSafe · Confidencedocs ↗ TypeSafe · Documentation homedocs ↗

Suggested next experiment: pick one high-volume classification problem, create a small labelled evaluation set, and compare Jev, a fine-tuned classifier, and an LLM baseline on quality, latency, cost, and escalation rate.

Thanks for reading · press O for overview, F for fullscreen, ← / → to navigate19 / 19
← / → navigate · O overview · F fullscreen