No chat, no prose, no parsing — that is the pitch in three negatives. Everything in that response object is machine-readable, so the application branches on it directly instead of scraping a sentence.

Documented claims are kept separate from illustration throughout: the stamp at the foot of each slide says which is which, and the key is on the final slide.

A companion deck, RLCD — The Mathematics of Calibrated Decisions, covers the probability theory behind the numbers shown here.

The docs describe the workaround in their own words: teams end up “coercing a text-generation system into outputting structured decisions, then parsing the results back into something your code can depend on.” The alternative: “System One models make fast, structured decisions for software,” returning “typed values and probability distributions that your code can branch on, sort by, and route with.”

Machine Native Intelligence is defined as “AI with software-like properties such as structure, reliability, observability, testability, speed, consistency, and low cost.”

TypeSafe's stated premise is that large-scale automation will consist mostly of machine-to-machine interactions, not human-facing chat — which shifts the design priority from readable responses to inspectable ones. The company explicitly does not aim to build an all-purpose model; text generation, explanation, and conversation are out of scope by design.

“Jev is TypeSafe's flagship model and the first System One model.” “jev-1.13 is not trained to generate text.” “Decisions and probabilities conform to the structured software types and JSON schema your code expects.” System One models are “trained for calibrated decisions: their probabilities are optimized against outcomes to reflect uncertainty.”

TypeSafe is the company. System One is the model category — named after the fast-intuition system in dual-process psychology. Jev is the flagship model in it; jev-1.13.0 is current and jev-latest is the SDK default alias.

Requests go to a single endpoint, POST /v1/systemone, with the model field selecting the version. Client SDKs exist for Python and JavaScript. The state is your content — a message, a record, an application snapshot; answers come back keyed by question id.

The documented claims: System One models “make fast, structured decisions for software,” “don't write replies or generate explanations,” and are “trained for calibrated decisions.” The escalation target is spelled out too — “escalate uncertain cases to a person or a more expensive reasoning model.” That is why the routing slides later matter more than any single accuracy number.

The System 1 / System 2 vocabulary was popularized by Kahneman's Thinking, Fast and Slow. It communicates intent but guarantees nothing; the properties that matter are the documented ones — typed outputs, a calibration target, text-only input, independent parallel questions.

Kahneman did not mean two literal systems or physical parts of the brain; they are conceptual labels for automatic versus deliberate processes. The key dynamic: System 1 usually acts first, and System 2 often just accepts its answer. That makes everyday life efficient, and it is also where the biases come from.

The analogy imports a useful warning: human System 1 is fast and biased. The jaggedness slide is exactly this model's bias list. Fast intuition needs slow verification around it, in machines as in people.

Jev is also “no longer the only claimant to the label” — the open-source Laya (chapter 04) calls itself a “System-1 decision model” too.

The docs' critique of RLHF: optimizing preference can encourage “sycophancy and confident-sounding hallucinations,” and narrows output diversity. RLVR optimizes what a verifier can confirm. RLCD's stated aim is that predictions marked 0.2 succeed about 20% of the time and those marked 0.8 about 80%.

A category alone cannot tell your application whether to act automatically or ask a person. A calibrated probability can be multiplied by the cost of being wrong and compared with the cost of checking — that arithmetic is the whole automation decision, and it only works if the probability honestly reflects how often outcomes occur.

“Human preference and machine trustworthiness are different optimization targets” is the docs' one-line version. These goals overlap; the claim is about emphasis. Reviewed sources state the goal, not the reward, loss, or update rule — the recipe itself is undisclosed. One biographical note the docs offer: TypeSafe cofounder Diogo Almeida co-invented RLHF.

“State is the content you ask a System One model to evaluate… The state contains the content and supporting facts. Questions define the judgments the model should make about that material.”

On shape: use an object “for most requests so each part of the state has a descriptive name and its relationships remain clear.” The build guide adds that you should reference exact values by path, like support.tickets[0].message, and keep the state lean — accuracy falls as unrelated content grows, and you pay per input token.

The documented rule: “Send every question that uses the same state in one request” — “one primitive's result does not become hidden context that changes another primitive's result.”

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()
response = client.system_one(
    state=ticket,                       # one state…
    questions={                          # …many judgments
        "department":  Choice(instructions="Which team should handle this",
                              criteria={"billing": …, "technical": …, "sales": …}),
        "frustration": Score(instructions="How frustrated the customer appears",
                             criteria=["Calm, just stating facts",
                                       "Frustrated but civil",
                                       "Very angry, strong language"]),
        "is_urgent":   Noul(instructions="The message conveys urgency"),
    },
)
response.answers["department"].choice   # "technical"
response.answers["frustration"].score   # 1.0
response.answers["is_urgent"].noul      # 1.0

Three question types, one API call, three typed answers.

The definition: “A Choice is a System One question type for selecting one option from a defined set. The answer includes the selected option, a probability for each option, and confidence.” Vague option descriptions are the documented cause of misclassification.

When options are similar enough to risk confusion, the docs recommend structured option objects with fields like what (the definition), not_for (what belongs elsewhere), and examples (typical cases). Examples strongly influence behavior — only use ones that match your real inputs.

Remember the companion deck's caution: the largest probability wins the selection, but it is not necessarily the cheapest action. A 41% winner in a three-way split may still warrant a human check.

The definition: “A Score is a System One question type for rating content against ordered, descriptive levels.”

Describe concrete situations, not abstract degrees. “Broken or degraded feature, but workaround exists” beats “moderately severe” — the model evaluates each level independently, so comparative language (“worse than the previous level”) means nothing to it.

One dimension per Score. Severity and urgency are two questions; a multifaceted judgment hides several answers behind one number.

Normalize before combining. To weight several Scores of different lengths together, divide each by its top level number first, then apply your domain weights.

A confident “middling” answer — nearly all mass on level 1 — and a bimodal “either trivial or catastrophic” answer can report the same score. The first is safe to act on; the second is precisely the case to escalate. The score alone cannot tell them apart, which is why the docs say “always examine probabilities and confidence.”

The next slide lets you build both distributions by hand and watch the number stay put.

The bars are set by your sliders, not by Jev — this page computes the weighted average locally to make the definition tangible. In a real response the distribution comes from the model, and a separate confidence field summarizes how concentrated it is.

The middle level's probability is whatever the two sliders leave over; if their sum exceeds 1, the widget rescales proportionally, so the three always sum to one — as in a real Score answer.

The second experiment is the point of the slide: push mass to the extremes until the score reads 1.00 with almost nothing on level 1. A bimodal “either trivial or catastrophic” distribution and a confident “middling” one can report the same score — which is why the score alone should never drive a high-stakes action.

The definition: “A Noul question asks the model to evaluate a yes/no question and return the probability that the answer is yes.” There is no separate confidence field — the number is the confidence. Near 0.5 means “yes and no get similar probability.” The docs' example is_human_escalation returns "noul": 0.99. The API identifier is noul; the docs don't explain the etymology.

Use a Noul when the answer is yes or no — does the message request a refund, does the résumé mention distributed systems, does the comment contain personal data. A question with multiple conditions (“urgent and from a paying customer?”) should become separate Nouls combined with boolean logic in your code.

From the jaggedness page: structural invariants across separate questions are not guaranteed — a Noul and its negation may not give probabilities summing to one. Ask one question, phrased so high means yes.

The documented guidance, verbatim: “Raise it when acting on a false yes is expensive, such as paging someone or issuing a refund. Lower it when missing a true yes is expensive, such as failing to flag a safety issue.”

That is the cost logic from the companion deck in miniature: the right cutoff is a ratio of the two error costs, not a universal number. The RLCD deck's fraud example works it out with actual dollar amounts.

Every Choice and Score answer carries a confidence: “a single number from 0 to 1” you can threshold on. It summarizes the distribution's shape — “concentrated on one outcome means a confident answer, spread out means an uncertain one.” Nouls have none; the probability is the answer.

The companion deck's lecture example makes the same point with a Choice: probabilities of 0.60 / 0.38 / 0.02 shipped with a confidence of 0.39 — not 0.60, and not derivable from the winner alone.

On low confidence the guidance is explicit: “do not act. Route to a human, request clarification, or fall back to a different system.”

“A confidence threshold is not one number. Different actions within the same system should be gated at different levels depending on the consequences of getting it wrong.” A destructive operation deserves a higher gate than a read-only one, even inside the same workflow.

“Start with conservative thresholds, test with your own data, and adjust as you observe results” — and from the build guide: plot confidence against accuracy on your own outcomes. That validation is what turns a heuristic into an engineering decision. The next slide makes the bands draggable.

Escalation is documented: uncertain cases go “to a person or a more expensive reasoning model.”

Gates too generous: drag “act above” down to 0.5. More answers auto-execute, including near-ties — fine for tagging, reckless for refunds.

Gates too timid: drag “escalate below” up toward the act gate. The confirm band vanishes and nearly everything lands on humans, which is the old manual process with extra steps.

Set each gate from the cost of that action going wrong, then validate by plotting confidence against accuracy on your own data. The defaults here (0.40 / 0.80) are arbitrary starting points for the demo.

Because answers are typed values rather than generated text, output is tiny and TypeSafe simply doesn't charge for it — the bill is a function of how much state you send. That makes the build guide's advice to keep state lean a cost lever as well as an accuracy lever.

At $0.042 per million input tokens, a 1,000-token state with a handful of questions costs on the order of hundredths of a cent — the “run it a million times in the background” use cases are priced deliberately.

Rate limits are “adjusting dynamically” under demand and may change without notice; pricing and limits are the vendor's to change.

The page opens plainly: “Jev isn't perfect. Here are some jagged edges we are aware of with jev-1.13.” A vendor documenting its model's failure modes is exactly the observability-and-testability posture the manifesto claims — and it gives you a concrete test plan: each row is a category of cases for your own evaluation set before shipping.

Ask Jev the semantic part and keep the arithmetic in code: “does this message mention more than one order?” is a bad question; “which orders does it mention?” plus len() is a good one.

Contradictory instructions: when instructions and criteria disagree, answers degrade — keep them aligned.

No text generation: by design rather than defect. When you need prose, pair Jev with an LLM — Jev decides, the LLM writes.

Recheck the jaggedness page when the model version changes; the list is versioned to jev-1.13.

Every entry has the same silhouette: a high-volume stream of small judgments, each cheap to make and cheap to check, feeding deterministic software that owns the consequences. None asks the model to converse, plan, or explain.

The inverse is a useful negative test: if your task needs one large, novel, multi-step judgment — a legal brief, an architecture decision — that is reasoning-model territory, and Jev's role shrinks to verifying pieces of it.

The docs' own phrasings are worth quoting: guardrails “at a fraction of the cost”; “build a custom router that chooses which LLM receives each prompt”; “replace or supplement embeddings in RAG pipelines”; moderation against “company-specific, nuanced criteria.” The cookbook has worked recipes for most of them — re-ranking, classifying RAG passages, double-checking citations, function calling, and guardrails.

The guide's wording: “Keep deterministic work in code. It is reliable and cheap.” Atomization is “probably the most important concept in this guide. Broad questions hide several judgments behind one answer.” Compose with “deterministic rules or weighted sums” — or feed the probabilities into a classical ML model. Reference exact values by path, like support.tickets[0].message.

Instead of one broad question — “should we refund this customer?” — the docs' refund example builds a state holding the customer's message, the transactions, and the policy, then asks independent questions together: does the message request a refund? (Noul) · is the order within the policy window? (Noul) · how frustrated is the customer? (Score) · which team owns this? (Choice).

The refund decision is then an auditable boolean expression in your code. When it misfires you can see which judgment was wrong — the observability a broad question destroys.

Zero-shot classifiers such as facebook/bart-large-mnli and GLiNER-style encoders “already do something similar.” Reddit and GeekNews verdicts include “essentially BERT with more data” and “I implemented the same functionality with BERT-family models years ago.” KDnuggets also places Jev outside “the same category as GPT, Claude, Gemini, or other frontier LLMs.”

Each ingredient has a citable history: fine-tuning pretrained encoders for classification (Devlin et al., 2018), zero-shot classification via NLI (Yin et al., 2019), and post-hoc calibration including temperature scaling (Guo et al., 2017).

What is documented: one shared set of weights for all accounts, no per-customer fine-tuning, and the task chosen at runtime by the question text — an operational difference from one-classifier-per-task, whatever the architecture turns out to be. The fair restatement of the claim is narrower than the marketing: not a new kind of AI, but engineering on a known recipe.

The flagship 0% hallucination figure “was plotted at zero because schema conformance is guaranteed by design” — the model cannot emit a value outside the options you defined, so the metric is true by construction and says nothing about whether the chosen option is right.

TypeSafe's accuracy benchmark scores Jev against frontier-model reference answers. That measures agreement with another model, not correctness, so it cannot support a general accuracy claim.

Neither observation says the product is bad — they say these two numbers are not evidence of quality. The next slide is someone actually measuring.

On phrasing robustness: the same question asked as a Noul returned 0.22 — asked as a yes/no Choice, “no” at probability 0.99. Measured calibration is task-dependent: ECE 0.154 on phishing (worse than Haiku's 0.097), 0.0712 on tool-call classification.

The decomposition workflow — five narrow questions, weights fitted on 1,000 labels — is where Jev won, and it pushes the logic onto the code side where it can be audited. That is the product's thesis working as advertised; it just required labeled data and fitting, like any classifier.

The regex's 91.8% cuts both ways: this synthetic benchmark was easy, which weakens both Jev's win and the criticism drawn from its single-question loss. GeekNews' top comment offers the charitable reading: “the skill of clearly communicating what something does and where it's useful is equally part of innovation.” Others noted the practical value plainly: solving a classification problem “in minutes instead of weeks.”

Laya (Convai Innovations) serves the three primitives with calibrated probabilities in one ~33 ms forward pass, 7.2 ms/question batched, and publishes its recipe: proper-scoring-rule reward with Gaussian logit noise. Its question schema is near-identical to Jev's.

From the Hugging Face model card (checked 27 September 2026): three checkpoints (English root 421M on ModernBERT-large, a 322M mmBERT multilingual variant, a typed-decisions fine-tune), 103–332 questions/second on a Tesla T4, and 45 of 51 tested languages above chance. Jev's ~239 ms median latency is from the independent test on the previous slide.

By Laya's own model card, its base checkpoints score 0.362 zero-shot against a 0.461 majority-class baseline — near random. The headline 0.766 is a fine-tuned checkpoint; ECE runs 0.213–0.466 before temperature refitting, and its noul “can follow its option labels instead of the state.”

The circulating head-to-head (accuracy 0.766 vs 0.727; ECE 0.081 vs 0.246) is Laya's vendor benchmarking its fine-tuned model on its own dataset — treat it exactly like TypeSafe's 68%: an advert until independently reproduced.

One further allegation in the GeekNews comments — that a sales-conversion demo model had outcome labels leak into training — is from a single anonymous commenter and is unverified; it is mentioned only so you know it exists.

If the audience takes one thing from this chapter: run Laya as your baseline before paying for anything.

The Jev snippet is the documented quickstart pattern (TypeSafeClient().system_one with Choice/Score/Noul objects) with this deck's billing example substituted for the docs' Stripe ticket. The Laya snippet follows its model card's Router.predict usage; the 0.892 noul is the card's own example output. Jev-side values will vary run to run — they are labels here, not reproduced results.

Both SDKs are pip-installable today. Laya also exposes laya.load("convaiinnovations/laya") for pinning a single checkpoint instead of the auto-routing Router.

The fine print each vendor states: Laya wants a fine-tune and a temperature refit before production; Jev wants confidence thresholds validated against your own outcomes.

This deck answers what Jev is and how to hold it: the product shape, the primitives, the documented limits, the build method. The companion deck, RLCD — The Mathematics of Calibrated Decisions, answers why the probabilities can be trusted and what to do with them: calibration, proper scoring rules, and expected-cost decisions.

Presented together, run this one first — the mathematics lands better once the audience has seen a real answer object with a probability distribution in it.

Sources: TypeSafe documentation (introduction, System One, primitives, confidence, models, jaggedness, use-case map, build guide), reviewed 27 September 2026, plus the third-party material listed on the next slide.

Provenance key in full: documented — reproduced from TypeSafe documentation; illustrative — local widgets and teaching devices, not model output; undisclosed — stated goals whose mechanisms the sources do not specify; third-party — external tests, commentary, and the Laya model card, quoted for balance, not endorsed.

Example values (the shoe ticket's 1.0, the bug's 1.43 / 0.35, the 0.99 noul) are reproduced from the documentation pages above and may change as the docs evolve.

Companion deck: RLCD — The Mathematics of Calibrated Decisions, which reviews the lecture video in this folder.