Status: Maintained working project reference
Originally compiled: 16 September 2026
Last documentation review: 9 October 2026
Model described at review: jev-1.13.0 (per TypeSafe's published model reference)
Scope: TypeSafe AI, System One Models, and specifically the Jev model
This is a project knowledge resource, not a product guarantee or a substitute for current documentation. It combines official TypeSafe statements, independent technical interpretation, illustrative examples and recommended engineering controls. Those categories should not be treated as interchangeable. The API and SDK examples were reviewed for structure and syntax but not run against a live TypeSafe account during this editorial pass.
| Area | Where to start |
|---|---|
| Understand Jev | Purpose (§1) · Executive summary (§2) · Mental model (§3) |
| Understand the interface | State (§6) · Primitives (§7) · Probability and confidence (§8) |
| Choose and design workflows | Suitability (§13) · Task shapes (§19) · Patterns (§20) · Workflow design (§30) |
| Understand risks and boundaries | Limitations (§22) · Technical constraints (§23) · Benchmark cautions (§24) |
| Build an integration | API (§42) · SDKs (§43) · Failures/retries (§44) |
| Prepare for production | Privacy/governance (§45) · Evaluation/readiness (§46) |
| Find primary material | Official sources (§40) · Documentation index |
This part explains Jev's mental model, typed judgements, architecture, strengths, limitations and workflow-design patterns. The more changeable API, SDK, reliability, privacy and evaluation details are collected in Part II (§§42–46).
This document provides the baseline knowledge required for any conversation, design exercise, technical investigation or project involving TypeSafe Jev.
When working in this project, do not treat Jev as simply another LLM, small language model, classifier, reasoning model or chatbot. Jev represents a different model/interface paradigm designed primarily for machine-consumed semantic decisions inside software.
Use this document as the default conceptual model unless newer TypeSafe documentation explicitly supersedes it.
Where a question depends on current pricing, limits, model versions, API behaviour or newly released features, verify those details against TypeSafe's latest documentation rather than assuming the values in this document remain unchanged.
Jev is TypeSafe AI's first public System One Model.
Its fundamental interface is:
Unstructured or structured state in → typed probabilistic decisions out.
Unlike conventional LLMs, Jev does not generate arbitrary text. Instead, developers define questions and their permitted answer spaces in advance. Jev evaluates those questions against supplied state and returns structured answers, probabilities and, where applicable, confidence values that software can use directly. (docs.typesafe.ai)
A useful shorthand is:
Code calculates.
Jev judges.
Reasoning models reason and generate.
Or, more specifically:
Jev is for fast semantic judgements where an ordinary
ifstatement needs understanding rather than arithmetic.
Examples include:
- Does this message indicate a safeguarding concern?
- Which department should handle this ticket?
- How severe is this incident?
- Does this passage support this claim?
- Which candidate passage is most relevant?
- Does this tool call appear unsafe?
- Which specialist model should receive this request?
- Does this document satisfy requirement X?
Jev is especially suited to performing large numbers of narrow semantic judgements cheaply, quickly and predictably inside normal software workflows.
Imagine putting all relevant information in front of a knowledgeable human expert and asking them one specific question.
If they could make the judgement almost immediately without:
- doing research;
- producing an explanation;
- constructing a plan;
- performing a long chain of reasoning;
- making several dependent decisions;
- or creating new content,
then the task is likely to be Jev-shaped.
This is a suitability heuristic, not a benchmark or a promise of accuracy. “Five seconds” describes the shape of a focused decision; it does not mean that Jev can perform every judgement a human could make quickly, nor that every Jev request completes in five seconds. A fast human judgement can still depend on expertise, missing context, calculations, contested facts or a level of risk that demands review.
A stronger test is whether:
- the question evaluates one well-defined property;
- the answer is a bounded Choice, Score or Noul;
- the authoritative evidence needed is already present in the supplied state;
- the answer does not depend on substantial research, exact calculations or several hidden reasoning steps; and
- the quality of the judgement can be tested against representative examples.
For example, “Does this supplied complaint explicitly request compensation?” is more naturally Jev-shaped than “What compensation is legally due, and what should we do next?” The latter requires facts, policy, calculations and procedural decisions outside one atomic semantic judgement.
TypeSafe describes System One questions as focused “gut-check” judgements: the sort of determination a knowledgeable person could make quickly given the right context. Complex judgements should instead be decomposed into multiple narrow questions and recombined in software. (docs.typesafe.ai)
Think of tasks across two dimensions:
AMOUNT OF THINKING
LOW / IMMEDIATE HIGH / DELIBERATIVE
─────────────────────┬─────────────────────────
│ │
BOUNDED │ ★ JEV ★ │ CODE + REASONING
OUTPUT │ │ MODEL / HUMAN
│ classify │
│ detect │ evaluate complex case
│ score │ strategy
│ route │ investigation
│ verify │ multi-factor decision
│ rank │
├────────────────────┼─────────────────────────
│ │
OPEN │ FAST LLM │ REASONING LLM /
OUTPUT │ │ HUMAN EXPERT
│ summarise │
│ rewrite │ deep research
│ draft │ architecture design
│ extract prose │ complex problem solving
│ │
└────────────────────┴─────────────────────────
Jev sits strongly in the top-left quadrant:
Bounded output + semantic understanding + fast judgement
A conventional LLM normally works approximately like this:
prompt/context
↓
reason/generate tokens sequentially
↓
text / code / JSON
↓
parse + validate
↓
software
Jev instead works conceptually like:
state
+
typed questions
↓
Jev
↓
probability distributions /
typed decisions
↓
ordinary application code
TypeSafe explicitly positions System One as AI-powered software rather than agent architecture. Code should own control flow, deterministic rules and side effects; Jev should supply narrow semantic judgements where ordinary deterministic logic is insufficient. (docs.typesafe.ai)
A Jev request contains state plus one or more questions.
State is the material Jev evaluates.
It can be:
- a string;
- a JSON object;
- an array;
- an application record;
- a message;
- a conversation;
- a policy;
- several related records;
- or other structured application state.
A useful analogy is:
State is everything you would place in front of a panel of experts before asking them to make a judgement.
TypeSafe recommends structured objects for most non-trivial requests so relationships between pieces of context remain explicit. Questions can refer directly to fields within this state. (docs.typesafe.ai)
Example:
{
"incident": {
"description": "Tenant reports...",
"service": "Supported Housing"
},
"policy": {
"safeguarding": "..."
},
"previous_events": []
}The empty previous_events array can be populated with actual event objects when available; the example above is valid JSON rather than pseudocode.
Then Jev questions might ask:
Does `incident.description` indicate an immediate safeguarding risk?
Does the incident described in `incident` meet the escalation
criteria in `policy.safeguarding`?
How severe is the apparent risk?
Current API implementation note (9 October 2026): Jev 1.13 accepts text-based state as a JSON string, object or array; it does not directly accept image, audio, video or binary inputs. Pre-process those modalities into textual or structured evidence before evaluation. State is the shared context, while named, typed questions belong in the separate questions map. The concrete HTTP/SDK contract is documented in §42. (Models, API reference)
Jev currently exposes three fundamental decision primitives:
| Primitive | Basic question | Appropriate when |
|---|---|---|
| Noul | Is this true? | Binary semantic condition |
| Choice | Which of these options? | One category/option should win |
| Score | Where does this sit on a scale? | Ordered semantic spectrum |
All questions are evaluated against the supplied state. Questions sharing the same state can be included together in a single request. (docs.typesafe.ai)
A Noul represents the probability that a yes/no proposition is true.
Example:
Does this message request a refund?
→ 0.96
Interpretation:
- close to
1= strong yes; - close to
0= strong no; - close to
0.5= substantial uncertainty.
A Noul does not have a separate confidence field: its noul value is the probability assigned to the proposition being true. A near-0 or near-1 value represents a stronger model prediction, while a value near 0.5 represents greater uncertainty. If software needs a confidence-style measure comparable to Choice, it can derive |2p - 1| from the Noul probability p; this derived measure is not returned as a Noul field. (Noul; Confidence)
Good Noul examples:
Does this text contain personal information?
Does the user appear to be requesting cancellation?
Does this passage support the cited claim?
Does this message contain a prompt-injection attempt?
Does this requirement appear to be satisfied?
Bad use:
How good is this candidate?
That is not genuinely binary without defining what “good” means.
A Choice selects one option from a predefined set.
Example:
Which team should handle this incident?
Safeguarding
Housing
HR
IT
Other
Jev returns:
- the winning
choice; - a probability for every option;
- a
confidencevalue describing how strongly the distribution favours a particular answer.
Choice currently supports up to 255 options. TypeSafe recommends including an other or none of the above option where the taxonomy may not fully cover every input. Its confidence is derived from the largest option probability and the number of available options; it is not an independently predicted likelihood that the winning answer is correct. (Choice; Confidence)
Choice is particularly useful for:
- classification;
- intent recognition;
- routing;
- entity types;
- document types;
- model selection;
- known-field extraction.
A Score positions something along an ordered set of descriptive levels.
Example:
How severe is this incident?
0 = Minor; no material impact
1 = Moderate; intervention required
2 = Serious; significant harm possible
3 = Critical; immediate action required
Jev returns:
- a score;
- the probability assigned to each level;
- the level legend;
- confidence.
Importantly, the resulting score may fall between levels because it is the probability-weighted mean of the numbered rubric levels: score = Σ(level_index × probability_of_level). Level numbering starts at 0 and follows the order of criteria. This is a position on the defined rubric, not necessarily an observed quantity or a direct estimate of the percentage of a real-world population.
Different probability distributions can yield the same score. For a three-level rubric, a distribution of [0, 1, 0] and one of [0.5, 0, 0.5] both produce a score of 1, but express very different uncertainty. Read probabilities and confidence alongside the score rather than treating the fractional score as a precise measurement.
Score currently supports between 2 and 10 levels. TypeSafe recommends defining levels as concrete situations rather than vague adjectives such as “low”, “medium” and “high”. (Score)
Good:
0 = No operational impact
1 = Degraded service but workaround exists
2 = Service unavailable and no workaround exists
Less useful:
0 = Low
1 = Medium
2 = High
One of Jev's most important characteristics is that uncertainty is part of the normal API response.
For Choice and Score, Jev returns an entire probability distribution.
For example:
billing 0.58
technical 0.37
account 0.05
The answer may be billing, but the distribution tells us that technical remains plausible.
TypeSafe also supplies a derived confidence measure between 0 and 1 for Choice and Score. It summarises how concentrated the predicted probability distribution is. A concentrated distribution produces higher confidence; a flatter or more dispersed distribution produces lower confidence. It is a statistic of the model's distribution, not a separately measured probability that the answer is correct. (Confidence)
This enables software to distinguish:
WHAT does Jev think?
+
HOW SURE is Jev?
These should often be treated as separate dimensions.
TypeSafe publishes the calculations underlying its confidence values. These make clear why confidence, the probability of the winning answer and actual accuracy must not be conflated.
Noul: The API only returns the yes-probability p, but applications can derive a confidence-style value if needed:
noul_confidence = |2p - 1|
Choice: For n options, with p_max the largest option probability:
choice_confidence = (p_max - 1/n) / (1 - 1/n)
This normalises the leading probability relative to a uniform distribution. The value depends on the number of supplied options and the top probability; it does not take the runner-up margin into account directly. Two distributions with the same top probability and option count can have the same confidence even if the remaining probabilities differ.
Score: Confidence also accounts for how far apart the plausible ordered levels are. It compares the probability-weighted distance from the most likely level against the average distance of a uniform distribution, floored at zero. Uncertainty spread across opposite ends of a scale is penalised more than uncertainty spread across adjacent levels.
For practical decisions, it may be more suitable to use the winning-option probability, the gap or ratio between the leading two options, or the full Score distribution. Validate whichever measure and thresholds are used against representative domain data. See TypeSafe's complete formulas and examples.
TypeSafe trains System One models using an approach it calls:
RLCD — Reinforcement Learning for Calibrated Decisions.
The intended property is that probabilities meaningfully represent uncertainty: groups of predictions carrying higher probabilities should prove correct more frequently than groups with lower probabilities. (typesafe.ai)
However:
Calibration does not mean that an individual prediction is guaranteed to be correct.
A result with high confidence can still be wrong. Equally, the reported confidence for a Choice or Score is a measure of distribution concentration, not evidence that the model has been calibrated on your specific domain or dataset. Calibration and error rates must be measured empirically. (Confidence)
Therefore:
- confidence should inform automation;
- thresholds should be validated against real domain data;
- high-risk actions should demand stronger evidence;
- uncertain cases should be escalated.
TypeSafe describes Jev as unable to hallucinate because output is constrained to predefined types and answer spaces. (typesafe.ai)
This needs careful interpretation.
If the available outputs are:
billing
housing
HR
IT
other
Jev cannot output:
"Probably ask Sarah because she normally deals with these."
It must return one of the supplied alternatives and its associated probability distribution.
Therefore Jev avoids an important class of LLM failure:
inventing an unexpected value or malformed output outside the schema.
It does not mean:
Jev cannot make an incorrect judgement.
Jev might confidently classify something as housing when the correct answer is safeguarding.
For this project, use the following terminology:
Type-safe / schema hallucination: effectively eliminated by design.
Semantic judgement error: still possible and must be measured.
Adversarially influenced judgement: still possible. An attacker-controlled passage included in state may steer Jev's probabilities or category selection, even though the response remains correctly typed. TypeSafe specifically documents this vulnerability for Jev 1.13. (Jev 1.13 jaggedness)
A valid Choice label, Score or Noul value is therefore not evidence that the underlying content was trustworthy, that the decision was justified, or that a prompt-injection attempt was resisted. Schema safety is a valuable guarantee about the form of a response, not about its semantic truth or security.
Never interpret “zero hallucinations” as “zero errors”, “zero prompt-injection risk” or “safe to execute without independent controls”.
A major architectural difference from autoregressive LLMs is that Jev evaluates independent questions in parallel.
If one state requires:
What type of incident is this?
Does it involve personal data?
Is there a safeguarding concern?
How severe is the risk?
Does policy require escalation?
Does the description indicate immediate danger?
Which team owns the case?
these questions should generally be sent together rather than serially. (docs.typesafe.ai)
TypeSafe says that adding questions typically adds very little latency, although the additional question text still contributes token cost and the total request must remain within the model's aggregate token limit. This is not a promise of identical end-to-end latency for every workload. (Primitives; Models)
This leads to an important Jev design principle:
Fan out semantic questions; compose their answers in code.
Questions within one Jev request are evaluated independently against the same state.
The answer to question A does not secretly become context for question B. (docs.typesafe.ai)
This is valuable because:
- adding another question should not change previous questions through conversational context;
- individual semantic features remain inspectable;
- workflows become easier to test;
- dependencies remain explicit in software.
If question B genuinely depends upon the result of question A, the application should make a subsequent request once A has determined the new state, options or data required.
Serial Jev calls should therefore represent genuine information dependencies, rather than simply copying an LLM conversational pattern.
Independence is not the same as deterministic repeatability. Question results are not passed between independent questions, but repeated evaluations are not contractually guaranteed to produce byte-for-byte identical probability values. TypeSafe publishes empirical Noul self-consistency tests; versioned regression and repeated-run checks remain advisable where stable numerical outputs matter.
When assessing a possible task, ask these six questions.
| Test | Question | Positive Jev signal |
|---|---|---|
| Judgement | Is AI deciding rather than creating? | Strong |
| Bounded | Can the answer space be defined beforehand? | Strong |
| Atomic | Can this be expressed as one focused judgement? | Strong |
| Context-contained | Can the information needed be placed in state? | Strong |
| Fast-human | Could a knowledgeable expert judge it quickly? | Strong |
| Machine-consumed | Will software use the result directly? | Very strong |
5–6 yes answers: excellent Jev candidate.
3–4 yes answers: Jev may handle parts of the workflow; decompose it.
0–2 yes answers: another technology is probably more appropriate.
Ask:
Can I express the requirement as “Given this state, tell me X”, where X is a Choice, Score or probability?
If yes, investigate Jev. Being expressible as a typed question is necessary, but not sufficient. Before selecting Jev, check that:
- Evidence is contained in state. The necessary material is available, current and sufficient; Jev is not being asked to research missing facts.
- The decision is genuinely semantic. Deterministic code should handle arithmetic, exact comparisons, dates, database lookups and known rules.
- The answer space is fit for purpose. Choices cover realistic cases (including
other/unknownwhen appropriate); Scores use clear, ordered levels; Nouls define what constitutes true and false. - The consequence is manageable. The workflow can validate results, apply risk-appropriate controls and escalate unclear or consequential cases.
A request can pass the syntax test yet fail these checks—for example, “Given no supporting records, is this supplier GDPR-compliant?” is a Noul-shaped question but an unsuitable evidence-free decision.
For example:
Given this supplier response:
Does it provide a production API?
→ Noul
What level of API maturity is evidenced?
→ Score
Which integration approach does it appear to offer?
→ Choice
Is the supplier's statement sufficient evidence for requirement R23?
→ Noul
This is highly Jev-shaped if the response and relevant requirements are supplied in state, the criteria are explicit, and downstream code owns the final decision. These separate questions are indicators of evidence, not a substitute for a formal procurement or compliance decision. (TypeSafe — How to build)
Another powerful mental model is:
Jev provides semantic conditions for ordinary software.
Traditional code handles:
if amount > 10000:
escalate()Jev enables a semantic condition in ordinary code:
# Example only: threshold must be validated for this use case.
if refund_intent_probability >= validated_routing_threshold:
route_to_returns_queue()Here, refund_intent_probability comes from Jev interpreting natural language rather than from an exact keyword match. The application still owns the threshold, routing rule and subsequent action.
Do not copy arbitrary thresholds into safety-critical workflows. For example, a safeguarding indicator might trigger early human review at a deliberately sensitive, empirically validated threshold:
if safeguarding_indicator_probability >= review_trigger_threshold:
flag_for_human_review()A value below that threshold must not be treated as proof that no safeguarding risk exists. Other evidence, mandatory escalation rules and human judgement may independently require action. The appropriate threshold depends on the costs of missed concerns as well as false alarms; the model's confidence alone does not determine safety. (Confidence)
This is what TypeSafe means when describing System One decisions as “smart if-statements” or programmable common-sense judgements embedded inside software. (Introducing System One Models & Jev)
A good Jev architecture generally looks like:
INPUT / APPLICATION STATE
│
▼
deterministic code
│
▼
┌─────────┐
│ JEV │
│ judges │
└────┬────┘
│
typed decisions
probabilities
│
▼
deterministic code
/ | \
/ | \
▼ ▼ ▼
ACT REVIEW REASONING
MODEL
The software — not Jev — owns the workflow.
TypeSafe's design guidance is:
- use deterministic code wherever possible;
- insert System One where semantic understanding is required;
- ask narrow questions;
- combine answers explicitly;
- use confidence to control automation;
- escalate genuinely difficult cases. (docs.typesafe.ai)
A useful higher-level architecture is:
OBSERVE
application data, messages, documents, records
│
▼
JUDGE
Jev semantic probabilities / typed decisions
│
▼
APPLY POLICY IN CODE
validated thresholds + hard rules + risk controls
│
├── low-risk, validated decision ──────► ACT
│
├── possible harm / mandatory rule ───► HUMAN / SAFETY ESCALATION
│
├── uncertain or incomplete evidence ─► REVIEW / GATHER EVIDENCE
│
└── requires multi-step reasoning ────► REASONING MODEL
│
▼
REVIEW / CONTROLLED ACTION
Jev often belongs in the judgement layer between raw application state and deterministic action. Certainty and consequence are separate inputs to routing: even a concentrated probability distribution must not bypass hard policy rules, permissions, independent verification or required human approvals.
For high-consequence use cases, an apparent absence of risk is also a prediction that can be wrong. Provide a safe path for concerning evidence that is missed, disputed or outside the chosen question's scope. (Confidence; Jev 1.13 jaggedness)
Use this heuristic:
| Need | Prefer |
|---|---|
| Exact deterministic calculation | Code |
| Database lookup | Code/database |
| Known business rule | Code/rules engine |
| Quick semantic judgement | Jev |
| Classification | Jev |
| Semantic scoring | Jev |
| Semantic verification | Jev |
| Ranking/relevance judgement | Jev |
| Complex multi-stage reasoning | Reasoning LLM |
| Research requiring external information | Reasoning/search system |
| Writing prose | LLM |
| Generating code | LLM/coding model |
| Explaining a conclusion | LLM/human |
| Novel strategic decision | Reasoning model/human |
The guiding shorthand is:
Code calculates. Jev judges. LLMs reason/create. Humans determine objectives and acceptable risk.
TypeSafe's many use cases largely reduce to a small set of reusable decision shapes. (docs.typesafe.ai)
What kind of thing is this?
Examples:
- intent;
- department;
- incident category;
- document type;
- entity type;
- risk category.
Typically: Choice
Is property X present?
Examples:
- fraud signal;
- urgency;
- sensitive data;
- safeguarding concern;
- jailbreak attempt;
- policy violation.
Typically: Noul
Where does this sit on an ordered semantic scale?
Examples:
- severity;
- relevance;
- quality;
- frustration;
- suitability;
- maturity.
Typically: Score
Which predefined code path should handle this?
Examples:
- department;
- specialist workflow;
- escalation path;
- tool selection;
- LLM/model selection.
Typically: Choice + confidence gate
Does this item semantically match what I need? Where is the answer within an already supplied, bounded document?
Examples:
- evaluating candidate passages against a query;
- identifying which tagged line or section of a supplied document answers a question;
- determining whether the document contains an answer at all.
Typically: Noul or Score for a query–candidate pair; Choice + Noul for a bounded set of tagged passages/lines.
Distinguish searching from finding candidates. For a large corpus, a search index, BM25, embeddings, database filtering or another retrieval system should usually produce a shortlist first. Jev can then evaluate those candidates. It is not itself a vector database, crawler or general-purpose full-corpus indexing engine.
TypeSafe also demonstrates direct semantic search within one bounded document: a Choice distributes probability across tagged line IDs and a companion Noul asks whether the answer exists. Because Choice always selects a leading option, an existence check is necessary to avoid treating the best irrelevant line as an answer. (Line-by-line search; Re-ranking)
Which already retrieved information should the downstream workflow receive?
Examples:
- selecting RAG evidence from retrieved passages;
- flagging evidence that contradicts the query's premise;
- excluding irrelevant or suspicious candidate passages;
- selecting policy sections for downstream verification.
Typically: Noul/Score judgements about each query–passage pair + deterministic filtering and selection.
The normal pipeline is:
CORPUS
↓
BM25 / embeddings / database retrieval (candidate shortlist)
↓
Jev assesses each candidate against the query
↓
Code filters, sorts, groups and applies policy thresholds
↓
Selected evidence → downstream workflow or reasoning model
Jev cannot rescue relevant items the first-stage retriever never supplied. In TypeSafe's RAG passage-classification cookbook, a candidate is separately checked for relevance, usable answer evidence, contradiction and prompt-injection signals; ordinary code decides what the answering model receives. (Classifying RAG passages)
Which items are best according to the same explicitly defined semantic property?
Examples:
- candidate passages;
- applications;
- recommendations;
- search results;
- cases requiring attention.
Typically: a repeated Noul or Score applied against consistent criteria, followed by sorting in code; or Choice over a bounded candidate set.
Ranking is relative to the candidate set and rubric. A Choice distribution is competitive across its options: the winning item may be weak in absolute terms if all candidates are poor. Include an explicit suitability/existence check or threshold where “none is good enough” is a valid outcome. When evaluating items separately, hold question wording and criteria stable so the resulting judgements are meaningfully comparable, then test ranking quality on labelled examples.
Does this artefact satisfy a particular condition?
Examples:
- citation supports claim;
- LLM output complies with policy;
- tool call is appropriate;
- document meets requirement;
- answer contradicts supplied context.
Typically: Noul / Choice
Turn unstructured material into numeric semantic signals such as:
purchase_intent 0.81
churn_risk 0.63
urgency 0.92
frustration 1.7
policy_alignment 0.74
These can then feed:
- deterministic logic;
- analytics;
- classical ML;
- risk models;
- forecasting.
The numbers above are illustrative signals, not verified predictions. For example, a churn_risk Noul is not automatically a calibrated probability that the customer will churn. Define the target precisely, validate it against observed outcomes and retrain or recalibrate any downstream predictive model as necessary. TypeSafe demonstrates turning semantic outputs into features for a separate classical ML model. (AutoResearch feature discovery)
Jev can recover known/bounded fields from unstructured input.
This differs from arbitrary generative extraction: Jev is strongest when values or candidate spans/options can be bounded or pre-parsed rather than asking it to manufacture arbitrary strings.
A useful division of labour is to parse candidate values in code → use Jev to select or classify the appropriate candidate → normalise and validate the selected value in code. For dates, code should also resolve relative expressions and perform exact date arithmetic. If the correct value is not among the candidates, the workflow should have an explicit unknown/review path. (Pre-parsed value extraction; Date extraction)
Ask every potentially useful independent question upfront.
┌─ category
├─ severity
STATE ── JEV ────┼─ urgency
├─ refund?
├─ safeguarding?
└─ frustration
Then code ignores answers that do not apply.
TypeSafe specifically recommends this because questions run in parallel. (docs.typesafe.ai)
Use both:
answer
+
certainty
Example:
high confidence + low consequence + validated decision
→ eligible for automatic action, subject to hard rules
uncertain result or important missing evidence
→ confirmation, additional evidence or review
high consequence, mandatory control or suspected harm
→ apply policy safeguards / independent verification / human approval
Thresholds should vary according to the consequence of a wrong decision, especially the harm from false negatives as well as false positives. A high confidence value only describes how concentrated Jev's predicted distribution is; it is not, by itself, a safety clearance or proof of correctness. Use observed outcomes on representative cases to decide whether to gate on Noul probability, Choice winning probability, the top-two margin, Score distribution, or a combined rule. (Confidence)
Do not ask:
Is this supplier good?
Instead:
API maturity
security evidence
implementation complexity
functional fit
commercial clarity
Evaluate each dimension separately and combine using explicit weights in code.
This makes the decision:
- explainable;
- inspectable;
- tunable;
- testable.
Changing business priorities then means changing weights, rather than hoping a rewritten prompt implicitly gives the right importance to each factor. (docs.typesafe.ai)
Jev can decide whether a request needs:
deterministic code
│
small/cheap model
│
specialist model
│
frontier reasoning model
│
human
Possible signals include:
- intent;
- complexity;
- risk;
- ambiguity;
- domain;
- required capability.
This can make expensive reasoning conditional rather than universal. (docs.typesafe.ai)
Because Jev is comparatively cheap and fast, it can potentially sit around expensive LLM calls:
INPUT
│
├─ prompt injection?
├─ sensitive information?
├─ prohibited action?
└─ correct model/tool?
│
▼
LLM
│
├─ answers question?
├─ contradicts evidence?
├─ citation supported?
├─ unsafe tool call?
└─ policy compliant?
TypeSafe specifically highlights verification, LLM guardrails and harness engineering as important Jev use cases. (Use-case map; Guardrails for LLMs cookbook)
Guardrail does not mean infallible security boundary. TypeSafe's documented Jev 1.13 failure modes include adversarial content in state influencing an answer. A Noul detecting prompt injection can therefore itself be fooled or miss an attack. Jev's guardrail role is to provide additional semantic signals, not replace authentication, authorisation, tool allowlists, deterministic input/output validation, least-privilege permissions, irreversible-action confirmation, and other hard controls. (Jev 1.13 jaggedness)
A robust guardrail workflow should:
- evaluate narrow, explicit hazards on inputs and outputs;
- include legitimate, borderline and adversarial examples when evaluating the resulting probabilities;
- use code to apply risk-dependent pass / review / block / support actions (not necessarily simple pass/fail);
- retain an escalation or safe-failure path where missed detections would have significant consequences.
TypeSafe's published guardrails cookbook illustrates this pattern, but its recorded example results were produced with jev-1.12, not Jev 1.13; evaluate the current pinned model on your own examples before reusing its thresholds. (Guardrails for LLMs)
Output is constrained by predefined schemas and answer spaces.
Software does not need to parse generated prose to recover the model's intended answer. (docs.typesafe.ai)
Probabilities are fundamental outputs rather than an afterthought.
This makes confidence-aware automation considerably more natural.
TypeSafe reports many System One evaluations around 100 ms, with its launch material describing approximately 70–500 ms end-to-end depending on workload. These are vendor-reported indicative figures, not an API latency guarantee. Network distance, request size, load, retries and integration overhead affect application-level response times. (How to build with TypeSafe; launch announcement)
This makes Jev potentially suitable for:
- synchronous APIs;
- interactive UIs;
- routing;
- real-time applications;
- high-volume background processing.
As of 9 October 2026, TypeSafe documents Jev 1.13 input pricing as:
$0.042 per million input tokens — $42 per billion.
Output tokens are free under the published model pricing, although token usage can still be reported in API responses. This is the model's input-token price, not an all-inclusive estimate of application costs, retries or other systems. (Models; launch announcement)
Pricing should be rechecked before making production financial decisions.
Many narrow judgements can share one state and execute together.
This makes broad semantic feature extraction unusually efficient.
Because outputs are structured numeric values, they naturally compose with:
ifstatements;- thresholds;
- ranking;
- weighted scoring;
- rules engines;
- classical ML;
- analytics;
- routing.
Business logic remains visible in code rather than being hidden inside an enormous prompt or agent loop.
The cost/speed profile makes Jev especially interesting for workloads that require:
thousands or millions of small semantic judgements
rather than a few expensive conversations.
Jev cannot replace an LLM for:
- drafting emails;
- answering conversational questions;
- writing reports;
- summarising into prose;
- generating code;
- producing explanations.
This limitation is deliberate. TypeSafe warns against trying to manufacture prose by chaining large numbers of Choices: doing so sacrifices the model's intended speed and quality advantages. Use a generative model for open-ended text instead. (Jev 1.13 jaggedness)
A question requiring several dependent reasoning steps is poorly shaped for Jev.
Example:
Considering regulatory risk, implementation complexity,
commercial implications, strategic direction and organisational
capacity, which supplier should Southdown choose and why?
This is a reasoning task.
Jev might instead evaluate the individual dimensions feeding that decision. Jev 1.13 can also struggle with indirection, double negatives and questions requiring multiple hops. Refer directly to the relevant fields of state and split dependent reasoning across code-controlled stages where needed. (Jev 1.13 jaggedness)
Jev works best where the answer shape can be defined in advance.
Open-ended discovery and novel answer generation are therefore weaker fits.
Type safety prevents malformed/unexpected outputs, not semantic errors.
Production systems must therefore:
- evaluate Jev on representative data;
- tune criteria;
- choose confidence thresholds;
- provide escalation paths;
- monitor performance;
- test prediction stability under harmless changes, including Choice option reordering;
- test realistic adversarial and misleading content rather than assuming typed responses are secure.
High probability or high confidence is not a correctness guarantee. Jev 1.13's documented limitations should be treated as version-specific test requirements, not merely theoretical cautions. (Jev 1.13 jaggedness)
Jev cannot reliably judge information it has not been given.
Poor state design can result in:
- missing evidence;
- distracting evidence;
- ambiguity;
- lower confidence;
- incorrect decisions.
TypeSafe recommends supplying relevant structured context rather than relying on knowledge encoded in model weights where authoritative/current information can be supplied directly. (How to build with TypeSafe)
For Jev 1.13, more state is not automatically better. Irrelevant detail can degrade accuracy (context degradation), and adversarial instructions embedded in state can influence judgements. Retrieve/filter relevant evidence first, keep source content explicitly separate from application criteria, and test how the model behaves on untrusted inputs. State filtering reduces exposure but does not itself guarantee resistance to manipulation. (Jev 1.13 jaggedness)
Bad:
Is this case serious?
Better:
Does the incident describe an immediate risk of physical harm
requiring intervention before the next routine review?
The decision boundary needs to be meaningful.
Jev 1.13 may read a question literally rather than infer the intended boundary conditions. Define included and excluded cases, reference the relevant state field, and ensure that instructions and criteria express the same condition. For Noul, do not accidentally reverse the meaning of true and false. For Choice, define options clearly enough that they do not overlap unnecessarily. (Jev 1.13 jaggedness)
Low confidence may be evidence that:
- criteria overlap;
- state is incomplete;
- the task contains several dimensions;
- the question is poorly defined.
Do not automatically respond by writing a much longer prompt.
First consider whether the task should become several questions. If a component is actually arithmetic, counting or calendar comparison, use deterministic code instead of turning it into another semantic question.
It returns decisions/probabilities, not a prose chain of reasoning.
If users require an explanation, software may need to retain the evidence and decision logic or use another model to produce a human-readable explanation.
The explanation model should not be treated as changing Jev's underlying decision unless explicitly designed to do so.
TypeSafe maintains an explicit Jev 1.13 jaggedness reference for the known weaknesses of this model version. These are vendor-documented behaviours, not a comprehensive or independent failure-rate assessment. They should directly inform workflow design and regression tests.
| Failure mode | What can go wrong | Preferred mitigation |
|---|---|---|
| Literal reading | Jev answers the exact phrasing, not the unstated intent, especially around negation and boundary conditions. | State the precise condition; make inclusion/exclusion criteria explicit. |
| Math and numbers | Counting items or words, arithmetic, numerical comparisons and interpreting encoded numeric representations can be unreliable. | Compute numbers, counts and conversions in code; let Jev judge the genuinely semantic aspect. |
| Date and time comparison | Date ordering, intervals and relative date reasoning can fail, particularly with mixed formats. | Extract bounded date components where appropriate; parse and compare dates using a real date/time library. |
| Indirection | Double negatives and multi-hop questions become less reliable. | Reference named state fields; split dependent judgements into simpler steps. |
| Large irrelevant state | Distracting content can reduce accuracy, even when within the token limit. | Retrieve, filter and structure only the evidence relevant to each judgement. |
| Adversarial content | Injected instructions, misleading framing or self-serving claims in state can steer the answer. | Treat state as untrusted data; use precise criteria, independent hard controls and adversarial tests. |
| Contradictory instructions/criteria | The model can be confused when the overall question and descriptions of answer options disagree. | Align instructions, criteria, and the intended meaning of each answer. |
| Choice option order | In some cases Jev favours earlier options, so reordering a taxonomy changes the selection. | Test representative inputs with permuted option orders; revisit ambiguous option definitions and routing logic. |
| Generation | Chaining Choices to imitate free-form text generation is slow and ineffective. | Use a generative model for prose; use Jev for bounded selection or verification. |
Important Score-specific caveat: TypeSafe also cautions that Jev 1.13 cannot reliably infer a precise continuous numerical measurement by interpolating between rubric levels. A fractional Score is a probability-weighted position on the defined scale, not a reconstructed physical quantity. (Jev 1.13 jaggedness — Math using Score)
- Boundary tests: Check missing information, negations, overlapping criteria and near-duplicate classes, not just easy examples.
- Permutation tests: For Choice, run a representative set of examples with options presented in different orders and inspect changes in outputs; there is no guarantee that reordering will leave probabilities unchanged.
- Adversarial tests: Insert user-authored instructions or misleading statements into the state and check whether they alter decisions inappropriately. Do not interpret a passed test set as proof of injection immunity.
- Deterministic cross-checks: Compare any count, total, threshold, duration or date against code-computed values rather than trusting Jev to calculate it.
- Evidence and review paths: Measure both false positives and false negatives. For high-impact decisions, keep hard policy checks and appropriate human review even when Jev reports high confidence.
The exact set and severity of failure modes may change between Jev releases. Re-run evaluation when updating a pinned model or allowing a moving model alias to advance. Include these tests in the deployment review and regression suite for each production Jev workflow.
As documented by TypeSafe on 9 October 2026, the current released Jev model is Jev 1.13 (jev-1.13.0).
| Identifier | Current target | Intended use |
|---|---|---|
jev-1.13.0 |
Versioned release | Pin a tested model version when consistency of production behaviour matters. |
jev-latest |
jev-1.13.0 |
Moving alias for the latest stable release; SDK default and documentation examples. |
jev-preview |
jev-1.13.0 |
Moving alias that can advance ahead of stable when preview builds exist. |
At the verification date, no separate preview build is listed. Because aliases can move, a deployment using jev-latest or jev-preview can receive changed answers after a release without changing its own code. The API response's model field reports the resolved versioned identifier: record it for traceability and re-evaluate thresholds before adopting a new version. (Models)
| Constraint | Current documented limit |
|---|---|
| Aggregate request budget | 64,000 tokens, across state plus all questions. |
| Per-question context budget | 32,000 tokens, for state plus the longest individual question. |
| Choice options | Up to 255. |
| Score levels | 2–10, inclusive. |
| Questions per request | Multiple Choice, Score and Noul questions may coexist and are evaluated independently against the same state, subject to the aggregate limits. |
The 64k and 32k constraints apply simultaneously. It is incorrect to describe 32k as the overall shared request budget: a large fan-out request can contain up to 64k tokens in total, provided the state-plus-longest-question constraint is also respected. (Models; Primitives)
| Item | Current documented value |
|---|---|
| Input-token rate limit | 100,000 tokens/second. |
| Request rate limit | 80 requests/second. |
| Standard input price | $0.042 per million tokens. |
| Output-token price | Free. |
| Rate-limit response | 429 Too Many Requests when either throughput limit is exceeded. |
TypeSafe states that these rate limits may change without notice while capacity evolves. Its official client SDKs use backoff and respect retry-after when supplied; higher limits are available under custom or enterprise plans. These numbers describe documented service limits, not guaranteed sustained throughput or end-to-end application capacity. (Models)
Jev 1.13 takes text-based state (strings, JSON objects or arrays of text values). It does not accept image, audio or video input directly. External systems should convert non-text sources into suitable text or structured fields before using Jev. (Models)
These are time-sensitive product details, not permanent architectural properties. Recheck TypeSafe's Models reference before new deployments or performance/cost commitments.
At launch, TypeSafe reported workflow results as high as approximately:
- 193.6× faster
- 444.6× cheaper
than comparison LLM workflows on its System One evaluation workloads. (typesafe.ai)
These numbers should not be interpreted as universal performance improvements.
TypeSafe itself states that:
- these are likely towards the high end of real-world gains;
- its evaluation workflows were built internally;
- bias may therefore exist;
- existing public benchmarks do not map cleanly to the new model interface;
- users should conduct private evaluations on their own workloads. (typesafe.ai)
For this project:
Treat TypeSafe's published performance figures as vendor evidence worth investigating, not universal guarantees.
TypeSafe's Jack & Jill & Jev case study describes the talent-matching service replacing Gemini 3.1 Flash Lite with Jev for an initial candidate-screening stage and subsequently using Jev across additional workflows. The company reports that the initial stage was deployed to production, while the comparative quality figures below came from an offline test involving 150 live roles.
| Measure | Gemini 3.1 Flash Lite | Jev | Interpretation |
|---|---|---|---|
| Cost per 1,000 candidates screened | $0.755 | $0.092 | About 88% lower for the measured screening stage |
| Median time to screen candidates for a role | 20.3 seconds | 10.3 seconds | About 49% faster end-to-end stage completion |
| Historic hiring-manager-selected candidates retained in the shortlist | 93.9% | 94.6% | The 0.7 percentage-point difference was not statistically significant in the reported test |
| Candidate ranking AUC | 0.924 | 0.933 | Slightly higher on the case study's evaluation data |
The case study estimates $265,000 annual savings at the then-current volume and $500,000 with projected growth; the latter is a forecast, not an already realised saving. These figures are vendor-published customer results for a specific workflow, not an independent benchmark or evidence that Jev universally matches Gemini's quality at the same cost reduction. Evaluate candidate shortlisting and other consequential uses against their own accuracy, fairness, governance and human-oversight requirements. (TypeSafe case study, 7 October 2026)
Jev was publicly introduced on 15 September 2026 and made available in early access, according to TypeSafe's dated launch announcement.
Therefore many important questions remain less independently established than for mature LLM platforms, including:
- independent benchmark reproduction;
- production reliability at large scale;
- long-term pricing;
- domain-specific calibration;
- failure modes;
- model evolution;
- architectural details;
- behaviour across unusual distributions;
- enterprise governance capabilities.
This project should retain healthy scepticism while exploring Jev's potential.
Current TypeSafe documentation identifies Jev use cases including: (docs.typesafe.ai)
How to interpret this list: the families below are possible applications and vendor-identified opportunities, not a claim that every named task is a fully supported product feature or has been independently benchmarked on Jev 1.13. The specific work must still be decomposed into supplied state, typed semantic questions, deterministic software and measurable success criteria. A business process containing a Jev judgement is not necessarily a process Jev can execute end to end.
The official cookbook index provides concrete pipeline examples. Check the model version and experiment date inside each cookbook before carrying any reported result or threshold into a current deployment; several examples use earlier Jev versions.
Embedding semantic decisions into reliable software workflows.
Low-latency semantic decisions inside interfaces, applications and games.
Applying semantic judgements across very large corpora or traces.
Checking:
- prompts;
- outputs;
- reasoning traces;
- extractions;
- tool calls;
- citations;
- policy compliance.
Supporting AI systems through:
- model routing;
- semantic context selection;
- guardrails;
- LLM failure detection;
- trace classification.
Including:
- semantic search within a bounded supplied document;
- reranking already retrieved candidates;
- candidate relevance;
- RAG context selection and verification.
In large collections, combine established search/retrieval infrastructure with Jev's semantic judgements. TypeSafe publishes examples for re-ranking, line-by-line semantic search, and RAG passage classification. These are different pipeline shapes rather than one built-in Jev search capability.
Including:
- evidence screening;
- paper classification;
- citation checking;
- methodology detection;
- knowledge-graph construction.
Including:
- intent;
- ticket routing;
- urgency;
- frustration;
- churn risk;
- refunds;
- response verification.
Including:
- evidence for competencies;
- role matching;
- experience classification;
- candidate prioritisation.
Including:
- suspicious characteristics;
- entity matching;
- evidence quality;
- risk prioritisation.
Including:
- missing clauses;
- policy violations;
- prohibited claims;
- compliance verification.
Including:
- toxicity;
- harassment;
- spam;
- fraud;
- sensitive information;
- unsafe advice;
- policy violations.
Using Jev's semantic probabilities as features alongside traditional structured data.
The predictive target and labels belong to the downstream analytical workflow; Jev's semantic probability is not automatically a validated forecast of a future event. TypeSafe's AutoResearch feature discovery illustrates a pipeline that trains and evaluates a separate classical model.
For financial, safeguarding, recruitment, legal and other high-consequence contexts, prefer evidence screening, triage and review-support over autonomous final decisions unless the whole workflow has independently validated safeguards and the necessary human oversight. Jev's bounded outputs and apparent confidence do not remove the need for domain policy, fairness checks, data governance or accountability. See §22 and the later production/governance reference additions.
Potential Jev-shaped enterprise tasks include:
Incident category → Choice
Immediate risk present? → Noul
Safeguarding indicators? → Noul
Severity → Score
Personal data involved? → Noul
Likely owning team → Choice
Policy requires escalation? → Noul
Requirement clearly answered? → Noul
Evidence quality → Score
Production API evidenced? → Noul
Write API evidenced? → Noul
Integration maturity → Score
Response category → Choice
Contradiction with requirement? → Noul
Complaint category → Choice
Severity → Score
Urgency → Score
Potential safeguarding issue → Noul
Compensation request → Noul
Service failure alleged → Noul
Executive escalation needed → Noul
Prompt injection suspected? → Noul
Contains sensitive information? → Noul
Tool call appropriate? → Noul
Response grounded in evidence? → Noul
Citation supports statement? → Noul
Request complexity → Score
Model required → Choice
Poor standalone Jev tasks include:
Write a board paper.
Research the housing-management software market.
Explain why this incident happened.
Design our enterprise integration architecture.
Summarise this meeting for staff.
Write Python code that fixes this API.
Decide our five-year digital strategy.
These require generation, research, deliberation or extended reasoning.
Jev may still perform subtasks within these workflows.
A strong anti-pattern is:
“Consider all of these factors and tell me what we should do.”
That generally hides several independent judgements inside one opaque decision.
Instead of:
Should we select Supplier A?
ask:
Functional fit → Score
Evidence completeness → Score
Security concerns present? → Noul
Integration maturity → Score
Implementation risk → Score
Requirement R12 satisfied? → Noul
Requirement R13 satisfied? → Noul
Then combine these according to explicit business rules.
When designing a workflow, follow this order. The order is recommended engineering practice, built around TypeSafe's published guidance: code controls the process, Jev provides narrow semantic judgements, and the whole application must be measured against actual outcomes. (How to build with TypeSafe)
If ordinary code can determine the answer exactly, use code.
Bad use of Jev:
Is invoice.total > £10,000?
Use:
if invoice.total > 10000:Look for points in the process where someone currently:
- reads;
- interprets;
- judges;
- categorises;
- scores;
- routes;
- verifies.
These are candidate Jev points.
Ask:
What evidence would a knowledgeable human require?
Supply that evidence explicitly. Prefer a structured object with clearly named fields and authoritative policy/evidence, excluding unrelated history. When questions assess different records, provide stable record IDs or specific state paths so the scope of each question is unambiguous.
Do not enlarge state merely to appear comprehensive: irrelevant material, misleading retrieved text and adversarial instructions can reduce judgement quality. (State; Jev 1.13 jaggedness)
Replace:
Is this a serious complaint?
with signals such as:
Does it allege significant service failure?
Is there potential harm?
Is there regulatory exposure?
How urgent is the requested remedy?
Is the complainant threatening legal action?
Each judgement should have one interpretable boundary. Define what evidence supports an answer, how ambiguous or missing evidence should be handled, and which facts must instead be established using authoritative records. Do not silently turn a risk signal into a determination that a legal or safeguarding threshold has formally been met.
Use:
yes/no → Noul
category → Choice
spectrum → Score
Then write contrastive criteria: for Choice, distinguish near-neighbour options with what, not_for and examples where useful; for Noul, make true and false conditions explicit; for Score, describe ordered and observable levels, not merely adjectives. Add an other or equivalent path when a Choice taxonomy might be incomplete.
Structured instructions and criteria can make complex definitions more maintainable than prose alone. Test whether changing the order of Choice options changes results (see §22). (Choice; Advanced: structure)
Ask independent questions together, including relevant speculative questions whose results software may ignore on some paths.
A later request is justified when new authoritative data, different candidate options or a prior output genuinely changes the state required by the next judgement. Do not split independent questions into serial calls merely to mimic a conversational agent. Record the extra token cost and evaluate whether speculative questions are worthwhile at the workload's volume. (Speculative fan-out)
Use:
- rules;
- thresholds;
- weights;
- decision tables;
- conventional software.
Keep scoring weights, inclusion thresholds, policy requirements and permitted side effects outside the model. A composite number should have a documented interpretation; where absolute numeric values or dates matter, calculate them separately and use Jev only for the semantic components. For ranking, use the same rubric across candidates and retain the underlying evidence and distributions.
Decide what happens when confidence is:
high
medium
low
Do not use the same confidence threshold for every consequence. Gate using the correct signal (Noul probability, Choice distribution/confidence, Score distribution or a measured combination) rather than assuming these quantities are interchangeable.
Define explicit accept / request evidence or confirmation / escalate or stop paths, including the case where Jev fails, times out or returns an answer unsupported by the evidence. Validate every threshold against observed false-positive and false-negative costs. In high-consequence workflows, deterministic safeguards and required human approvals still apply even with high model confidence. (Confidence-gated routing)
Measure:
- accuracy;
- false positives;
- false negatives;
- calibration;
- confidence vs accuracy;
- cost;
- latency;
- escalation rate.
Also evaluate coverage of unknown/other cases, stability under Choice-option reordering, distractor/adversarial inputs, reviewer agreement, and performance by relevant subgroup or input type. For retrieval/ranking, measure candidate recall, precision at K and whether relevant evidence is actually passed downstream. Use a held-out test set and compare against deterministic baselines or an alternative classifier; vendor cookbook metrics are not a substitute for local evaluation.
Treat model outputs as measurable system components rather than magic.
Log the resolved model version, question/rubric version, request outcome, bounded metrics and escalation route. Track changes in input mix, error rate, score distributions, calibration and human overrides; investigate drift before lowering review thresholds. Protect personal/confidential state in logs, and plan for model upgrades to require regression testing. Detailed production governance controls belong in the later dedicated reference section.
For any proposed use case, capture:
USE CASE:
What business problem are we solving?
STATE:
What information will Jev receive?
SEMANTIC DECISIONS:
What individual judgements are required?
PRIMITIVES:
Which are Noul / Choice / Score?
DETERMINISTIC LOGIC:
What should remain ordinary code?
DEPENDENCIES:
Which decisions genuinely require earlier results?
CONFIDENCE ACTIONS:
What happens at high / medium / low confidence?
RISK:
What is the consequence of a wrong decision?
ESCALATION:
Human, reasoning model, extra evidence, or other?
VOLUME:
How many judgements occur?
LATENCY REQUIREMENT:
Batch/background/interactive/real-time?
GROUND TRUTH:
How will we establish whether Jev is correct?
EVALUATION:
How will accuracy and calibration be measured?
VALUE:
Does Jev improve cost, speed, reliability or scalability
compared with the existing approach?
Jev becomes increasingly attractive when several of these are true:
- semantic interpretation currently requires humans;
- the decision happens frequently;
- the answer belongs to a known space;
- there is lots of unstructured text;
- the workflow already exists in software;
- deterministic rules are too brittle;
- LLM calls would be disproportionately expensive;
- latency matters;
- probabilities are useful;
- uncertain cases can be escalated;
- the task can be evaluated against ground truth.
Jev becomes less attractive when:
- tasks are rare;
- stakes are extremely high and judgement cannot be validated;
- answers are fundamentally open-ended;
- users expect prose;
- long chains of reasoning are required;
- authoritative context cannot be supplied;
- evaluation criteria cannot be defined.
Jev and frontier reasoning models should usually be seen as complementary, not mutually exclusive.
A strong architecture may be:
INPUT
│
▼
DETERMINISTIC CHECKS / POLICY
│
├─ Known exact operation ──────→ ordinary code / database
│
└─ Semantic judgement needed
│
▼
JEV
(Choice / Score / Noul)
│
▼
CODE APPLIES RISK GATES
│
├─ bounded routine case ──→ specialist workflow / code
├─ content generation ───→ appropriate generative LLM
├─ complex reasoning ───→ reasoning model
└─ uncertain / high risk ─→ human review / stop
This diagram deliberately puts deterministic checks before Jev where they can resolve a request without model inference. Jev does not independently decide which actions it is authorised to take: application code chooses the permitted path using the typed results and the relevant rules. A mandatory human gate is not bypassed merely because Jev is confident. (Intent routing)
Jev can help determine when expensive intelligence is necessary, provided the routing task itself is a sufficiently narrow, validated judgement.
This is particularly important economically.
Instead of:
100% of requests → expensive reasoning model
a system hypothetically might route its workload as follows:
70% → deterministic/Jev path
20% → lightweight model
8% → reasoning model
2% → human
These percentages are invented solely to illustrate the architecture. They are not TypeSafe benchmark results, measured adoption rates, expected savings or recommended targets. Actual routing proportions depend on the input mix, safety requirements, model quality, thresholds and human-review policy. Some workflows should send substantially more than 2% to human review.
Measure the end-to-end baseline before asserting an economic benefit: count extra Jev and retrieval calls, tokens, retries, false-route handling, second-stage model use, human review and delay. A cheaper first-stage judgement is valuable only where total workflow quality and cost improve at an acceptable level of risk. (Intent routing; Confidence-gated routing)
The deepest way to think about Jev is not as an application.
It is closer to a new software primitive.
Traditional software primitives provide operations such as:
boolean comparison
integer arithmetic
database lookup
HTTP request
regular expression
Jev potentially adds:
semantic judgement
So software can ask:
Does this mean X?
Which known thing is this?
How much does this resemble Y?
Does this satisfy Z?
and receive a machine-consumable probabilistic answer.
This is central to TypeSafe's idea of machine-native intelligence.
The terminology is inspired by Daniel Kahneman's distinction between:
System 1
Fast, intuitive judgement.
System 2
Slow, deliberate reasoning.
TypeSafe applies this distinction to machine intelligence.
Jev is designed around:
fast
focused
bounded
probabilistic
semantic decisions
rather than long-form deliberation. (docs.typesafe.ai)
Do not overextend the psychological analogy; it is primarily a useful description of the computational role TypeSafe is targeting.
When answering questions within this project:
Do not spend several paragraphs reintroducing Jev unless the explanation is relevant.
Its interface, training objective and intended architecture are materially different.
Assess whether the individual semantic judgements are Jev-shaped.
When a task seems too complex, look for Jev-compatible sub-decisions rather than immediately declaring the whole use case suitable or unsuitable.
Do not use AI where exact code is available.
Ask whether the task is:
"judge this"
or:
"work out what to do"
The former is much more Jev-shaped.
Do not immediately discard them by reducing everything to hard labels.
Consider confidence thresholds, human review and reasoning-model escalation.
Jev can still be wrong.
Pricing, models, limits and early-access behaviour can change rapidly.
For technical claims, current TypeSafe documentation and model/API material should be preferred over secondary commentary.
TypeSafe documentation, its Privacy Policy and its DPA describe vendor positions and contractual terms. They do not independently establish that a particular organisation has signed the necessary agreements, configured retention, approved international transfers, or assessed its own intended processing. Distinguish verified vendor claims, specific contractual commitments, local policies and proposed engineering safeguards. See §45.
Do not assume that no model training implies no retention, that removed names imply effective anonymisation, or that a confident Jev judgement authorises a consequential action. Classify state before transmission, minimise its contents, validate decisions against representative cases and retain human or deterministic controls where required. See §§45–46.
Record model ID, question/rubric revision, state-building logic, thresholds and deterministic decision rules for any production workflow. Re-evaluate changes against held-out cases and maintain a rollback/fallback plan, even when the API shape remains unchanged. See §46.
Use this when a short explanation of Jev is needed:
TypeSafe Jev is the first System One Model: an AI model designed for fast, bounded semantic decisions inside software rather than text generation. Applications provide structured or unstructured state and ask typed questions using Choice, Score or Noul primitives. Jev returns constrained decisions and probability distributions that ordinary code can threshold, rank, combine and route on. Its strengths are very low latency and cost, native uncertainty, type-safe outputs and efficient parallel evaluation of many independent judgements. It is best suited to classification, detection, scoring, routing, verification, semantic re-ranking, context selection and feature extraction. It is not intended to replace reasoning LLMs for open-ended generation, research, complex multi-step reasoning or explanation.
Jev is a fast probabilistic semantic decision engine for software: state in, typed judgements out.
When inspecting a workflow, look for:
“Someone needs to look at this and decide whether…”
That is often a Jev opportunity.
Compare:
“Someone needs to work out how…”
That is more likely reasoning.
And:
“Someone needs to write…”
That is generation.
Therefore:
Use official documentation for current product behaviour. The TypeSafe documentation index is the best starting point for discovering newly added or reorganised pages. The product/API and legal references below were reviewed on 9 October 2026; their contents, service limits and terms may change. The launch article is useful historical vendor evidence, not the definitive source for current technical limits.
| Resource | What it establishes |
|---|---|
| Introduction | Jev's purpose and the System One interface |
| System One | The conceptual distinction from generative LLMs |
| State | Supported context structure and state design |
| Primitives | Choice, Score and Noul; independent typed questions |
| Advanced question structure | Structured instructions and criteria |
| Confidence | The published confidence calculations and their interpretation |
| How to build with TypeSafe | Code-owned control flow, semantic decisions and decomposition |
| Patterns | Fan-out, confidence routing, composite scoring and intent routing |
| Use-case map | Intended application families and examples |
| Resource | What to check there |
|---|---|
| Models | Current versions/aliases, price, context limits, languages and throughput |
| HTTP API reference | Request and response fields, validation and error behaviour |
| Quick start | Minimal call examples and first integration |
| Client SDKs | Official client options |
| Python SDK and RetryPolicy | Python code and retry configuration |
| JavaScript SDK | JavaScript/TypeScript client, types and usage |
| TypeSafe status page | Published API and console service status and incidents; supplement with your own telemetry |
| Jev with coding agents and Agent skill | Using coding agents to develop Jev integrations (not using Jev as a coding model) |
| Jev 1.13 jaggedness | Model-specific documented failure modes; last reviewed by TypeSafe on 2 October 2026 |
The Cookbooks index is the maintained catalogue. Particularly relevant examples include:
- Speculative parallel questions — comparing batching with separate calls.
- Re-ranking and classifying RAG passages — candidate retrieval followed by semantic evaluation.
- Line-by-line semantic search — bounded document-line selection, not a hosted search index.
- Guardrails for LLMs and citation checking — model judgements used as verification signals.
- Self-consistency: Nouls and Choices — experiments on stability, abstention and automation coverage.
- Structured data extraction cascade, date extraction and pre-parsed value extraction — combining Jev with deterministic code and other models.
- AutoResearch feature discovery — using semantic probabilities as inputs to conventional predictive modelling.
Reading rule: A cookbook's measured results belong to its particular data, sampling period and model version. They should not silently be treated as current performance guarantees for a pinned jev-1.13.0 deployment. See §§24 and 46.
- System One / Jev launch article (15 September 2026) — vendor explanations of RLCD, motivation and original benchmark claims, not a replacement for the current Models page.
- Jack & Jill & Jev case study (7 October 2026) — TypeSafe-published customer deployment results, including quality comparisons from an offline test and cost/speed figures for a particular candidate-screening stage; not an independently reproduced general benchmark (see §24).
- TypeSafe legal overview, Privacy Policy and Data Processing Addendum — published legal statements that require contract-specific assessment before corporate use.
- ICO DPIA guidance, anonymisation guidance and pseudonymisation guidance — independent UK data-protection guidance relevant to §45.
Source discipline for this project: Distinguish (1) documented vendor claim, (2) result from a vendor cookbook, (3) independently verified fact, and (4) recommendation for a particular organisation. If a new Jev release supersedes these references, revise model-specific limits and tests instead of silently projecting Jev 1.13's behaviour onto it.
The project's default mental model should be:
BUSINESS / APPLICATION STATE
│
▼
deterministic facts & rules
│
▼
┌────────────────────────┐
│ JEV │
│ │
│ semantic judgements │
│ │
│ Choice / Score / Noul │
└────────────┬───────────┘
│
probabilities +
typed decisions
│
┌────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
CODE REASONING MODEL HUMAN
normal path difficult cases exceptional /
high-risk cases
Jev should therefore be thought of primarily as:
a programmable semantic judgement layer inside ordinary software
rather than:
a chatbot, autonomous agent, general-purpose reasoning model or replacement for all LLMs.
That distinction should underpin all Jev-related analysis, architecture and experimentation in this project.
The preceding sections establish the conceptual model and design principles. Part II is an implementation reference: concrete API shapes, SDK usage and operational failure handling. These details change more frequently than the conceptual guidance above.
Verification date for §§42–46: 9 October 2026. The examples use the official Jev 1.13 API/SDK documentation and the then-published TypeSafe legal materials. §§45–46 distinguish documented vendor positions from recommended organisational, legal and engineering controls. Recheck model identifiers, contracts, subprocessors, retention terms and technical limits before deploying.
TypeSafe's evaluation API is a single HTTP endpoint:
POST https://api.typesafe.ai/v1/systemone
Authorization: Bearer <API_KEY>
Content-Type: application/jsonGenerate an API key in the TypeSafe console. Send it in the Bearer header from trusted server-side code; do not embed it in a browser application, a public repository or source examples. The standard SDKs read the TYPESAFE_API_KEY environment variable. (Quick start, API reference)
Discover the names available to your account with:
curl https://api.typesafe.ai/v1/models \
-H "Authorization: Bearer $TYPESAFE_API_KEY"GET /v1/models returns a models array containing name, description and release_date. It currently lists aliases, so an accepted pinned version (such as jev-1.13.0) might not appear in that list. jev-latest is the default SDK alias; pin the specific version where behaviour has been validated and a moving alias would be undesirable. (Models)
Every evaluation request has three required top-level properties:
| Field | Shape | Meaning |
|---|---|---|
model |
string | Versioned model ID or alias, e.g. jev-latest or jev-1.13.0 |
state |
string, JSON object or JSON array | Shared text or structured evidence evaluated by all questions |
questions |
object / map | Application-defined question IDs mapped to typed question objects |
Question IDs are your application's identifiers: corresponding answers use the same keys, but the keys themselves are not passed to the underlying model for inference. Therefore put essential meaning in the instructions/criteria, not only in the question ID. Each question evaluates against the supplied state independently; it cannot see sibling answers. (API reference, Primitives)
| Question | Required fields | Optional / important detail |
|---|---|---|
| Noul | type: "noul", instructions |
criteria may describe true and false cases |
| Choice | type: "choice", instructions, criteria |
criteria maps candidate strings to descriptions; descriptions may be null; maximum 255 options |
| Score | type: "score", instructions, criteria |
criteria is an ordered array of 2–10 level descriptions; ordering determines score indices |
instructions can be a string, JSON object or JSON array. Choice option descriptions and Score level descriptions can also be structured. Use structured questions where they make evidence, scope and boundaries easier to maintain. (API reference, Advanced: structure)
The following is an authored example, not a recorded inference result. It deliberately asks several narrow, independent questions about one helpdesk ticket.
curl -X POST https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer $TYPESAFE_API_KEY" \
-H "Content-Type: application/json" \
-d @- <<'EOF'
{
"model": "jev-1.13.0",
"state": {
"ticket": {
"description": "The office Wi-Fi drops every few minutes. I have a client demo this afternoon.",
"site": "HQ, Building 2",
"status": "new"
}
},
"questions": {
"has_scheduled_commitment": {
"type": "noul",
"instructions": "Does `ticket.description` mention a scheduled event that could be affected?",
"criteria": {
"true": "An upcoming meeting, demonstration or other event is mentioned",
"false": "No upcoming scheduled event is mentioned"
}
},
"owner": {
"type": "choice",
"instructions": "Which team should initially investigate `ticket`?",
"criteria": {
"it_helpdesk": "Devices, Wi-Fi, networks and account access",
"facilities": "Physical premises, rooms and building maintenance",
"other": null
}
},
"operational_impact": {
"type": "score",
"instructions": "Rate the operational impact described in `ticket.description`, using only information actually supplied.",
"criteria": [
"No disruption to work is described",
"Work is degraded or intermittent, but not explicitly blocked",
"Work is explicitly blocked or a named scheduled commitment is at risk"
]
}
}
}
EOFFor Windows PowerShell, the request body can instead be saved as request.json and sent using a standard HTTP client; the shell heredoc syntax above is for POSIX shells.
Design notes: The event detector, owner classifier and impact score use different primitives. The descriptions are intentionally concrete. A system can evaluate all three in one call, then apply explicit business rules to the results; don't ask Jev itself to perform an irreversible follow-on action. (Quick start, Speculative fan-out)
Top-level response fields are:
| Field | Meaning |
|---|---|
model |
Resolved versioned model that performed the evaluation |
answers |
One typed answer per question ID |
usage.input_tokens / usage.output_tokens |
Token usage reported for this request |
The answer payload varies by question type:
| Noul | Choice | Score |
|---|---|---|
type, noul |
type, choice, probabilities, confidence |
type, score, legend, probabilities, confidence |
For example, the following synthetic response fragment illustrates field names and shape only; the probabilities are not results of running the request above:
{
"model": "jev-1.13.0",
"answers": {
"has_scheduled_commitment": {
"type": "noul",
"noul": 0.98
},
"owner": {
"type": "choice",
"choice": "it_helpdesk",
"probabilities": {"it_helpdesk": 0.90, "facilities": 0.08, "other": 0.02},
"confidence": 0.85
},
"operational_impact": {
"type": "score",
"score": 1.2,
"legend": {
"0": "No disruption to work is described",
"1": "Work is degraded or intermittent, but not explicitly blocked",
"2": "Work is explicitly blocked or a named scheduled commitment is at risk"
},
"probabilities": {"0": 0.05, "1": 0.70, "2": 0.25},
"confidence": 0.55
}
},
"usage": {"input_tokens": 650, "output_tokens": 70}
}Do not equate any example values with accuracy guarantees. Choice probabilities sum to approximately one; Score's numeric value is the probability-weighted rubric index (here 0×0.05 + 1×0.70 + 2×0.25 = 1.20). Confidence describes distribution concentration, not proven correctness. usage does not imply output tokens are currently charged; see §21 and §23. (API reference, Confidence)
- Validate inputs and bound candidate sets before sending the request; use code for exact arithmetic, dates and deterministic rules.
- Keep each question focused. Prefer one request containing several independent questions, rather than chaining them without an information dependency.
- Use a catch-all Choice option where real inputs might fall outside the taxonomy; this reduces forced classifications but doesn't eliminate misclassification.
- Inspect the complete distribution and use case-specific safeguards before acting; don't assume a high score or confidence is enough.
- Record the resolved response model for reproducibility, even when the request used an alias.
- Keep any API keys out of stored request examples, diagnostics and user-facing error messages.
These are recommended engineering practices informed by the documented interface, not additional promises made by TypeSafe.
| Environment | Supported route | Requirements / notes |
|---|---|---|
| Python | typesafe-sdk |
Python 3.10+; sync and async clients; optional http2 extra |
| JavaScript / TypeScript | @typesafe-ai/sdk |
Node.js 20+; inferred answer types, ESM/CommonJS/TypeScript definitions |
| Other languages or platforms | HTTPS REST API | Send authenticated JSON requests to /v1/systemone |
| Coding agents | TypeSafe agent skill | Teaches an LLM-powered coding agent to implement Jev integrations; not a substitute inference model |
See the official Client SDKs, Python, JavaScript, and Jev with coding agents references.
Recommended dependency control: Pin the specific Python/JavaScript SDK version used by a production integration and retain the project's resolved dependency lockfile. SDK versions and Jev model versions are independent. Pinning jev-1.13.0 does not pin client behaviour: SDK updates may affect request handling, retry defaults, timeout/error handling or response parsing. Review the Python SDK changelog and JavaScript SDK changelog, run integration/regression tests, and promote dependency changes deliberately. This is recommended software-engineering practice, not a vendor statement that particular versions are incompatible.
python -m pip install typesafe-sdk
# Or, in a uv project:
uv add typesafe-sdkSet TYPESAFE_API_KEY using your environment or secret-management mechanism. The following SDK example uses the current documented TypeSafeClient, Choice, Score and Noul interface:
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
state = {
"message": "The office Wi-Fi keeps dropping and my client demo is this afternoon."
}
with TypeSafeClient() as client:
result = client.system_one(
state=state,
questions={
"has_deadline": Noul(
instructions="Does `message` mention an upcoming scheduled commitment?"
),
"owner": Choice(
instructions="Which team should initially investigate `message`?",
criteria={
"it_helpdesk": "Wi-Fi, devices, networks and accounts",
"facilities": "Building and physical room issues",
"other": None,
},
),
"impact": Score(
instructions="Rate the work disruption indicated by `message`.",
criteria=[
"No disruption stated",
"Intermittent or degraded operation",
"Work blocked or a scheduled commitment at risk",
],
),
},
)
print(result.nouls["has_deadline"].noul)
print(result.choices["owner"].choice)
print(result.choices["owner"].probabilities)
print(result.scores["impact"].score)TypeSafeClient is synchronous; AsyncTypeSafeClient provides an asynchronous client and can be used with async with / await. The SDK uses jev-latest unless a model is specified, so see §23 for when to pin a version. HTTP/2 is available with typesafe-sdk[http2]. (Python SDK, Quick start)
The example above demonstrates API syntax; it has not been executed against a live TypeSafe account as part of this document revision. For production, validate the actual returned probabilities and exception behaviour in your own environment.
npm install @typesafe-ai/sdkimport { choice, TypeSafeClient } from "@typesafe-ai/sdk";
const client = new TypeSafeClient(); // Reads TYPESAFE_API_KEY
const response = await client.systemOne({
state: { message: "The office Wi-Fi keeps dropping." },
questions: {
owner: choice("Which team should handle this?", {
it_helpdesk: "Wi-Fi, network, device or account issues",
facilities: "Physical premises and buildings",
other: null,
}),
},
});
console.log(response.answers.owner.choice);
console.log(response.answers.owner.probabilities);This follows TypeSafe's published systemOne, choice() and response.answers conventions. TypeScript derives answer types from the question definitions, making supported response shapes easier to handle safely. Calls should run on a trusted backend rather than exposing the API key in frontend bundles. (JavaScript SDK)
The official skill helps Claude Code, Codex and other compatible generative coding agents create code that calls TypeSafe correctly. Its purpose is to teach an agent about the Jev API, primitive types and implementation patterns; Jev itself does not write code or replace the model running the coding agent. (Jev with coding agents)
TypeSafe documents this installation route for skill-compatible environments:
npx skills add typesafe-ai/skills --skill typesafe-aiInstallation may prompt for a target agent and may place files in the project. Review third-party skill instructions before enabling them in a corporate development environment. Official reference: Agent skill and skill repository.
- Python: natural for batch evaluation, analytics, evidence processing, server jobs and async pipelines.
- JavaScript / TypeScript: natural for backend request routing, web application services and strongly typed integration code.
- REST: appropriate where there is no SDK, e.g. a language-specific integration service or an existing HTTP-capable platform.
- Coding-agent skill: useful while writing or maintaining integrations; it is documentation/tooling rather than a model runtime.
These are practical design recommendations, not an official claim that one SDK has inherently better inference quality. Every route uses the same underlying model endpoint when configured with the same model and questions.
The official API reference documents JSON error responses with standard HTTP status codes:
| Status | Meaning | Recommended caller behaviour |
|---|---|---|
401 Unauthorized |
Missing or invalid credentials | Correct the key or configuration; do not blindly retry |
422 Unprocessable Entity |
Request failed validation | Correct the payload or question schema; do not blindly retry |
429 Too Many Requests |
Request/token rate limit exceeded | Exponential backoff; honour retry headers where supplied |
529 Overloaded |
TypeSafe temporarily overloaded | Back off and retry within a bounded retry budget |
Network failures and timeouts also need handling even when no HTTP response arrives. Avoid assuming that any response which isn't a valid typed answer should be treated as a negative Noul, the first Choice option or a score of zero. Those are model outcomes, not infrastructure fallback values. (API reference, Python SDK exceptions)
TypeSafe documents automatic retries with backoff in its SDKs for rate limits and overload responses. If calling REST directly, implement bounded exponential backoff with jitter and honour Retry-After when present. (Client SDKs, API reference)
The Python SDK exposes RetryPolicy for tuning retry count, retryable status codes, initial/maximum backoff, jitter, timeout and retry-header behaviour. Example based on the official retry reference:
from typesafe_sdk import RetryPolicy, TypeSafeClient
with TypeSafeClient(
retry=RetryPolicy(
max_retries=3,
timeout=10.0,
http_statuses={429, 500, 502, 503, 504, 529},
)
) as client:
# Call client.system_one(...) with the application's state and questions.
passHere, 529 is deliberately included in the custom retry set because it is a documented API overload status; the list above is a recommended policy example, not a statement of the SDK's exact default status-code set. Retry totals and deadlines must be chosen for the application's latency and risk requirements. (RetryPolicy, API reference)
These are separate control paths:
CALL JEV
|
+----------+----------+
| |
VALID ANSWER CALL FAILED
| |
inspect probability/ bounded retry
confidence |
| success / fail
code decides |
ACT / REVIEW / defined fallback / queue /
REASON / STOP human review / STOP
A low-confidence answer is not an API failure. Equally, a timeout is not evidence that a claim is false. Maintain separate metrics for inference quality, service reliability and application decisions.
For each decision seam, explicitly choose the behaviour when the Jev service cannot produce a usable result:
| Situation | Example fallback |
|---|---|
| Non-critical UI personalisation | Use a safe default or omit the enhancement |
| Background classification/reporting | Queue for later evaluation with traceable status |
| Operational work routing | Send to a general/manual queue rather than guessing a specialist |
| High-consequence safety, compliance or financial action | Apply deterministic safety controls; stop or require authorised review |
These are recommended production patterns, not guaranteed features of the TypeSafe API. Never skip mandatory policy/approval checks just because Jev is unavailable or appears highly confident.
Jev evaluates state and returns typed decisions; it does not execute the business action. The application should:
- Parse and validate the typed answer and its model version.
- Apply deterministic business rules, risk thresholds and required authorisations.
- Decide whether to act, obtain more evidence or escalate.
- Execute external side effects through ordinary application code, with appropriate idempotency and audit logging.
- Capture enough metadata to investigate errors without unnecessarily retaining sensitive source content.
If the application retries a workflow following an ambiguous failure, ensure that side effects are not unintentionally duplicated (for example, refunds, notifications or record updates). This is a general software-engineering requirement, not a Jev-specific ability.
Recommended log fields include:
- Application workflow/correlation ID and question IDs.
- Requested alias/version and resolved response
model. - Outcome category: successful evaluation, validation error, authentication error, rate-limited, overloaded, timeout or other failure.
- Request duration, number of attempts, retry count and fallback path used.
- Input/output token usage returned by the service.
- Selected answer, relevant probability/score/confidence and the code-side action taken, when appropriate to retain.
- Schema/prompt/rubric revision identifiers so behaviour changes can be investigated separately from model-version changes.
Log source text, records and identifiers only when necessary, authorised and consistent with the organisation's information-governance requirements. See §45 for privacy and governance, and §46 for evaluation, rollout and monitoring.
For potential provider-side incidents, consult TypeSafe's official status page, which publishes status for api.typesafe.ai and console.typesafe.ai. Treat the page as supplementary evidence, not a substitute for local health checks, request-level telemetry, service-level commitments or the application's fallback procedure.
Sources for §§42–44: API reference, Models, Quick start, Python SDK, Python RetryPolicy, JavaScript SDK, TypeSafe status page, Jev with coding agents, Documentation index.
Status of this section: verified against the official TypeSafe legal pages and UK Information Commissioner's Office (ICO) guidance on 9 October 2026. This is a practical engineering and governance reference, not legal advice, a representation that a particular contract has been executed, or an independently audited certification of TypeSafe's practices.
The important questions are not merely “Will Jev use the data for training?” but also “What data are we sending, for what purpose, under which agreement, from which jurisdiction, for how long, and with what safeguards?”
| Area | Documented vendor position | What the customer must still verify |
|---|---|---|
| Training and fine-tuning | TypeSafe's Privacy Policy states it will not train or fine-tune AI/ML models on customer prompts or other Input. | Contractual applicability to the intended account and the complete processing arrangement. |
| Hosting and international transfers | The Privacy Policy states that TypeSafe's services are hosted in the United States. | Whether a different hosting arrangement has been agreed, where each subprocessor processes data, and the organisation's applicable transfer assessment. |
| Data processing terms | TypeSafe publishes a Data Processing Addendum (DPA) addressing controller/processor obligations, security, data subjects, subprocessors and transfers. | Whether the operative agreement incorporates that DPA; legal review and execution/acceptance as appropriate. |
| UK transfer mechanism | The published DPA incorporates the UK Addendum to the EU standard contractual clauses for relevant UK transfers. | Whether the transfer mechanism is valid and appropriate for the particular data flow, together with any required transfer risk assessment and supplementary measures. |
| Subprocessors | The DPA points to TypeSafe's subprocessor register and provides notice/objection provisions. | Current identities, roles, locations, changes and applicability. A link is not equivalent to completing supplier due diligence. |
| Retention | The Privacy Policy and DPA describe retention by reference to necessity, services and applicable law; they do not give one universal fixed retention period for every API request. | Exact request/response and log retention, backups, deletion timelines and any customer-specific commitments. |
| Zero data retention | TypeSafe's legal documentation page says zero data retention (ZDR) is offered for enterprise customers. | Whether it is contracted and enabled for this account, what data and operational logs it covers, and whether any exceptions apply. |
| Security and incidents | The DPA commits to appropriate security measures and to notifying customers without undue delay and within 72 hours after TypeSafe becomes aware of a defined security incident. | Evidence of controls, escalation contacts, incident procedures and whether the contractual wording covers the intended data. |
Critical distinction: No training ≠ no retention ≠ UK-only processing ≠ automatic UK GDPR compliance. These are separate properties and must be checked separately.
TypeSafe's DPA also refers to its Trust Centre for technical and organisational safeguards. Do not infer a specific SOC 2/ISO certificate, UK data centre, encryption implementation, or contract-specific deletion guarantee merely from the existence of a Trust Centre; obtain current evidence and review scope before making such claims.
Official sources: TypeSafe legal documentation, Privacy Policy, Data Processing Addendum, subprocessor register.
Where the input contains personal data, a typical arrangement is that the organisation determines the processing purposes and means and TypeSafe processes on its behalf; the specific legal roles must be checked against the actual arrangements. TypeSafe's DPA describes the customer as controller/business and TypeSafe as processor/service provider for Customer Personal Data; more complex chains may involve another controller and a processor-to-subprocessor relationship.
Before deployment, the organisation should establish:
- Purpose and necessity: What narrow semantic judgement is needed, and why is transferring these fields necessary?
- Data categories: Will state contain personal data, special-category data, operationally sensitive material, confidential contracts, credentials or third-party material?
- Legal basis and transparency: Where personal data are involved, what is the lawful basis and what notice, rights handling and contractual processing instructions are needed?
- Contract and transfers: Does the applicable agreement/DPA cover this workload, including location and subprocessors?
- Risk assessment: Does the processing require a formal DPIA, other supplier/security reviews or a documented decision that a DPIA is unnecessary?
- Retention and access: Who can view submitted data, request logs, derived judgements, audit trails and exported datasets, and for how long?
- Decision authority: Who owns the business consequence of an incorrect model judgement and who may approve or reverse it?
The ICO says a DPIA is required when processing is likely to result in high risk to individuals, and recommends DPIA-style assessment for other major projects involving personal data. A DPIA is not automatically required for every Jev evaluation; neither is one waived simply because the vendor says it does not use inputs for training. See ICO: data protection impact assessments.
Check the DPA's data-subject categories, not just the data types. The published TypeSafe DPA, Schedule I identifies the categories of data subjects as “Customer and Customer’s users” and describes sensitive data transferred as “N/A”. Neither wording, on its own, establishes that a proposed workload involving identifiable tenants, clients/service users, employees or contractors is covered by the operative processing schedule. Nor does the wording necessarily prohibit all such processing: before transferring identifiable third-party information, the organisation should confirm with its information-governance/legal function and TypeSafe that the actual agreement accurately describes the intended data subjects, personal-data categories, any special-category data, instructions and safeguards. Obtain an amendment or additional written terms where necessary.
Do not treat “N/A” as approval for special-category processing. For genuinely anonymous input, the personal-data provisions may not apply to that anonymised content, although confidentiality, security and other contractual obligations may still apply. See §45.3 for the distinction between anonymised and pseudonymised information.
When using extracts or backups of operational systems, removing names and email addresses is not by itself proof that information is anonymous. Small groups, rare events, detailed free text, dates, locations, persistent reference numbers and combinations of attributes may enable a person to be singled out or re-identified.
Distinguish the following:
- Genuinely anonymous information: individuals are not identifiable by means reasonably likely to be used in the particular context; the UK GDPR does not apply to the anonymous information itself, though the process of anonymising source personal data can still be personal-data processing.
- Pseudonymised information: direct identifiers may be hidden, replaced or separated, but the data remain personal data where attribution/re-identification is possible; data protection requirements still apply.
- Confidential but non-personal business information: may be outside personal-data legislation yet remain subject to confidentiality, contractual, security and intellectual-property controls.
Illustrative enterprise example: For analysis of an anonymised housing-management database, prefer a limited, de-identified and checked export rather than sending an entire backup. Review free-text records, rare tenant/property combinations, contractors' details, staff audit trails, identifiers and linkable dates. If the extract is genuinely anonymous, document why; if not, treat it as personal data and apply the relevant governance controls. This example is a design recommendation, not a conclusion about any real dataset's status.
UK sources: ICO: introduction to anonymisation, ICO: pseudonymisation, ICO: what is personal data?.
A recommended production pattern is:
AUTHORITATIVE SOURCE / USER INPUT
|
v
CLASSIFY DATA + AUTHORISE USE
|
v
REDACT / MINIMISE / SELECT RELEVANT FIELDS
|
v
VALIDATE SCHEMA + REMOVE SECRETS
|
v
JEV: STATE + TYPED QUESTIONS
|
v
NORMALISE ANSWERS + APPLY RULES
|
+----> LOG MINIMAL METADATA / AUDIT EVENT
|
+----> HUMAN REVIEW WHEN REQUIRED
|
v
AUTHORISED APPLICATION ACTION
Recommended controls:
- Keep API credentials in a backend secret store, never in browser JavaScript, a public repository or request
state. - Validate and minimise the outbound
stateat the application boundary; remove unrelated records and secrets even if they would fit within the token limit. - Separate untrusted user/document text from trusted application instructions, rubrics and policies. This improves auditability but does not guarantee protection from prompt injection (§22.9).
- Protect data in transit, stored source records and locally retained decision logs according to organisational policy. Verify supplier-side security using the supplier's current evidence rather than assuming individual technical measures.
- Set an appropriate retention and deletion policy for the organisation's own copies, including evaluation fixtures, caches, traces, error reports, screenshots and backups.
- Limit access to underlying cases and derived outputs; even a probability or category may reveal sensitive information about an individual.
- Where human review is required, record the reviewer, relevant evidence and disposition without unnecessary replication of personal data.
These are recommended engineering controls; the TypeSafe API does not enforce the organisation's lawful basis, minimisation, authorisation or downstream retention policy on its behalf.
Model output is a signal, not permission to act. In particular:
- Deterministic obligations take precedence. Mandatory approval thresholds, access rights, safeguarding procedures and legal requirements must be enforced outside Jev.
- Different errors have different costs. A false negative on a safety concern and a false positive on a routine tag do not justify the same threshold or automated response.
- Human-in-the-loop is a designed control, not an emergency afterthought. Define who reviews uncertain, contested or high-risk outcomes and how they correct a decision.
- Do not claim explanations the model did not provide. Record evidence, question criteria and the application rule that led to an action; generated explanations are not a substitute for a decision audit trail.
- Assess fairness and bias where decisions affect people. Check error rates across legally and operationally relevant groups where lawful, necessary and feasible. Do not infer protected characteristics merely to populate an evaluation report.
- Follow source-system permissions. A caller's ability to use Jev is not authorisation to read, export or act upon any record in the source system.
Before approving a Jev workflow, keep a brief record using this template:
WORKFLOW / OWNER:
PURPOSE AND INTENDED OUTCOME:
TYPE OF INPUT STATE AND SOURCE SYSTEM:
PERSONAL / SPECIAL-CATEGORY / CONFIDENTIAL DATA PRESENT?:
ANONYMISATION OR MINIMISATION EVIDENCE:
LAWFUL BASIS / POLICY AUTHORITY (IF APPLICABLE):
CONTRACT / DPA / SUBPROCESSOR REVIEW STATUS:
INTENDED DATA-SUBJECT CATEGORIES / DPA SCHEDULE COVERAGE:
REGIONS / TRANSFER MECHANISM / ASSESSMENT:
REQUEST, LOG AND OUTPUT RETENTION / DELETION:
ACCESS CONTROLS / SECRET MANAGEMENT:
DPIA SCREENING AND RESULT (IF APPLICABLE):
CONSEQUENCE OF WRONG DECISIONS:
REQUIRED HUMAN / DETERMINISTIC CONTROLS:
APPROVER / APPROVAL DATE / NEXT REVIEW DATE:
Do not pre-fill a required legal conclusion solely from a vendor website. Record supporting evidence, ownership and unresolved items instead. Refresh the record whenever the state content, supplier contract, business use, intended decision or processing location changes.
Status of this section: based on TypeSafe's Confidence, Jev 1.13 jaggedness, Models and published self-consistency material, supplemented by recommended evaluation and software-engineering practices. The checklists and suggested metrics below are not vendor-certified pass marks.
A working API call only demonstrates technical integration. Production readiness requires evidence that the judgements, thresholds, failure handling and business consequences are acceptable on the specific workload.
Build an evaluation set from cases that resemble production, with privacy protections appropriate to the source. For each case, capture:
- a stable, non-identifying case ID, relevant input-state version and source/period;
- a human-verified answer or documented rubric outcome for each question;
- who reviewed the case and whether disagreements were adjudicated;
- a relevant evidence reference, not an invented model explanation;
- the expected downstream action or escalation path;
- known ambiguity, incompleteness and any need for an unknown/abstain route.
Sample across common and rare cases, borderline decisions, different input styles, long and short state, missing fields and known failure modes. Include cases where none of the Choice options should apply. Where appropriate, use a time-separated set to check changes in operating conditions.
Split data into development, validation and held-out test portions (or a carefully justified alternative). Do not repeatedly adjust questions or thresholds based on the held-out test set and then report that same set as an independent success result.
For subjective judgements, define an agreed reference rubric, use more than one independent human reviewer on a subset, record disagreements and resolve them consistently. A high agreement score with a poorly defined label is not reliable ground truth.
| Primitive / workflow | Useful measures | Important caution |
|---|---|---|
| Noul | Confusion matrix at a chosen threshold; precision, recall, false-positive/false-negative rates; Brier score or calibration bins | A probability is not a hard yes/no decision until application code selects an operating threshold. |
| Choice | Per-class precision/recall, macro-average, confusion matrix, top-choice probability, unknown/other handling, abstention/coverage | Class imbalance can hide poor rare-class performance; ordering and taxonomy changes may affect results. |
| Score | Per-level distributions; rubric-level agreement and ordered-error measures; calibration of level probabilities | The returned fractional score is a probability-weighted rubric index, not an exact physical or financial measurement. |
| Routing / automation | Correct-route rate, mistaken-action rate, manual-review rate, coverage, override rate, end-to-end outcome | Evaluate the entire code decision path, not merely the model's leading category. |
| Operations | p50/p95/p99 latency, request errors, timeouts, rate limits, retries, token use, cost per successfully handled case | Vendor latency benchmarks are not production service-level objectives. |
When rare positives matter (such as safeguarding or serious compliance breaches), overall accuracy alone may be misleading. Prioritise the specific error type that causes greatest harm while measuring the effect on operational workload and false alarms.
For calibrated probabilities, compare predicted likelihoods with observed frequencies across suitable bins; use reliability diagrams or a proper scoring rule (such as Brier score). Report uncertainty when sample sizes are small. A high confidence value is not empirical proof that a label is correct (§8–9).
A recommended threshold-setting process is:
- Decide which application actions are permissible and which always require an authorised person or deterministic rule.
- Identify the relative consequence of false positives, false negatives and unnecessary review.
- Run representative labelled cases through a pinned model, fixed question definitions and the real state-building pipeline.
- Compare candidate thresholds using expected error rates, action coverage and review demand.
- Choose the operating point using agreed risk appetite and capacity; document why.
- Lock that configuration and evaluate on held-out data before rollout.
- Monitor actual outcomes and reopen the decision if evidence changes.
Possible gating inputs include Noul probability, Choice top probability, top-two margin, Choice confidence, full Score probabilities, business rules and externally verified evidence. There is no universally safe value such as 0.90 or 0.95, and the same gate should not automatically be applied to every class or risk level.
In the official Choice self-consistency cookbook, adding an uncertainty/abstention path changes both agreement and how many decisions can be automated. This is a specific vendor experiment, not proof that its example threshold generalises to other datasets or Jev versions. (Self-consistency: Choices)
For Jev 1.13, design tests that deliberately exercise the documented weaknesses (§22.9):
- Option order: permute Choice criteria without changing their meanings and compare outcomes.
- Numerical/date assertions: vary counts, arithmetic, dates and temporal ordering; check exact facts independently in code.
- Negation and indirection: compare straightforward questions with equivalent double-negative or multi-hop forms.
- Context length and distractions: compare minimal relevant state with noisy or lengthy state; detect degradation.
- Missing/contradictory evidence: include incomplete records and conflicting policies; ensure the fallback/abstention route is safe.
- Prompt injection: place hostile instructions inside untrusted source text and check whether results are inappropriately influenced.
- Repeated evaluations: measure label flips and probability variation on near-boundary cases.
- Input distribution: include real-world abbreviations, language variants, OCR/transcription errors or domain-specific terminology where they occur in production.
Keep the malicious test material clearly identified as test data, not trusted instructions. Do not infer from successful tests that the model is immune to attacks or will behave identically after an alias points to a newer version.
Treat a Jev-powered decision policy as several coupled, versioned elements:
DECISION POLICY RELEASE
= source/state preparation revision
+ question IDs, instructions and criteria revision
+ Jev versioned model ID
+ SDK/client version and locked dependency revisions
+ thresholds and deterministic business rules revision
+ approved action, review and fallback policy
At minimum, capture the requested model name and the resolved model returned by the API. jev-latest and jev-preview are moving aliases; if calibrated thresholds depend on a particular model, pin a versioned ID and explicitly evaluate later releases before changing it. TypeSafe documents this behaviour on its Models page.
Also record the SDK package version and resolved dependency lockfile/revision (or the version of a custom REST client). A pinned model does not freeze transport, retry, timeout or response-mapping behaviour. Test SDK/client upgrades against known fixtures and error paths before rolling them into production; see §43.1.
A sensible release sequence is:
- Offline evaluation: meet pre-agreed acceptance criteria using representative labelled cases.
- Shadow mode: evaluate alongside the current workflow without permitting Jev to change outcomes; compare decisions and operational metrics.
- Limited/canary release: enable tightly scoped low-risk use with auditability and fast reversal.
- Controlled expansion: widen coverage only while evidence supports acceptable outcomes and human-review capacity.
- Rollback/fallback: revert the policy, switch off automation or use the established non-AI path if quality or reliability deteriorates.
Use normal change-control and authorisation for consequential actions. A model upgrade, revised Choice taxonomy, changed state extractor or threshold change can each alter real outcomes even if the API endpoint is unchanged.
Recommended production telemetry:
| Category | Monitor |
|---|---|
| Reliability | Timeouts, 429/529, error rate, retries, request durations, fallback queue size |
| Economics | Input tokens, request frequency, retry overhead, cost per evaluated case and completed workflow |
| Prediction behaviour | Per-question category and score distributions, Noul probability bands, confidence/abstention rates |
| Outcomes | Confirmed mistakes, review overrides, wrongly automated actions, missed critical cases, customer/staff impact where measurable |
| Drift | Changes in source schemas, document templates, input language/length, category prevalence, new failure patterns |
| Governance | Resolved model versions, criteria/policy revisions, approvals, access violations and retention exceptions |
Set organisation-defined alert thresholds based on baselines and consequences. Monitor performance at representative intervals, with periodic human-labelled audit samples to detect silent semantic deterioration. An apparently stable confidence distribution is not proof of stable accuracy.
Prefer minimal, structured audit records. The actual user text and other sensitive source fields should not be exported into general-purpose telemetry automatically. See §45.4 and §44.6.
Use this as a recommended release gate, assigning an owner and evidence location for each item rather than treating ticked boxes as a guarantee of safety.
- Purpose, owner, affected people and business consequence defined.
- Data categories classified; anonymisation/minimisation assessed and recorded where claimed.
- Relevant data-protection, contract/DPA, transfer, subprocessors and retention checks completed.
- DPIA screening performed and any required DPIA or other assessments approved.
- API secrets, access controls, logging and deletion arrangements reviewed.
- Model ID pinned or explicit moving-alias policy approved; resolved version logged.
- SDK/client dependency versions recorded and pinned, with upgrade/regression testing agreed.
- State preparation, questions/criteria, thresholds and application actions version controlled.
- Ground-truth dataset is representative, adjudicated where needed and protected appropriately.
- Held-out evaluation meets predefined, domain-specific acceptance criteria.
- Relevant Jev 1.13 jaggedness, repeated-call stability and adversarial tests completed.
- False-positive, false-negative, review-rate and fairness concerns considered where relevant.
- Infrastructure errors are distinguished from uncertain but valid model answers.
- Retry policy, timeouts, service limits, fail-safe behaviour and fallback tested.
- Mandatory deterministic checks, authorisations and human review remain enforceable.
- Audit trail, operational monitoring, alerting and incident route established.
- Shadow/canary rollout and rollback plan documented.
- Named approver accepts residual risk and schedules periodic reassessment.
Use this alongside the use-case assessment in §31 and the governance record in §45.6:
WORKFLOW / DECISION POLICY ID:
OWNER / REVIEWERS:
BUSINESS IMPACT OF A WRONG ANSWER:
STATE PREPARATION REVISION:
QUESTIONS / CRITERIA REVISION:
REQUESTED MODEL / RESOLVED MODEL:
SDK / CLIENT VERSION AND LOCKFILE REVISION:
THRESHOLD / ACTION RULE REVISION:
GROUND-TRUTH SOURCE / LABEL QUALITY / SAMPLE SIZE:
DEVELOPMENT / VALIDATION / HELD-OUT TEST SPLIT:
KEY METRICS AND PRE-AGREED PASS CRITERIA:
RESULTS INCLUDING ERROR TYPES / RARE CASES:
CALIBRATION / ABSTENTION / HUMAN-REVIEW RATE:
VERSION-SPECIFIC FAILURE / INJECTION TEST RESULTS:
API RELIABILITY / LATENCY / COST MEASUREMENTS:
PRIVACY / SECURITY / CONTRACT APPROVAL REFERENCE:
FALLBACK / ROLLBACK / OVERRIDE PROCEDURES:
DECISION: APPROVE / RESTRICT / REJECT / RETEST
APPROVER / DATE / NEXT REVIEW:
The release criterion is evidence, not confidence theatre: Jev is ready for a particular production task only when the full workflow's measured risks and operating behaviour are acceptable to the people accountable for that task. Some narrow, low-risk judgements may support direct automation; more consequential decisions may require independent evidence, deterministic controls and human authorisation regardless of the model's apparent certainty.
Sources for §§45–46: TypeSafe legal overview, TypeSafe Privacy Policy, TypeSafe DPA, TypeSafe Models, TypeSafe Confidence, Jev 1.13 jaggedness, Self-consistency: Choices, ICO DPIA guidance, ICO anonymisation guidance, ICO pseudonymisation guidance.
- Baseline: Originally compiled 16 September 2026; this consolidated edition incorporates Batches 1–6 and the targeted post-review amendments verified on 9 October 2026.
- Verified against: Public TypeSafe model, API, primitive, confidence, SDK, jaggedness and legal references available at the review date, plus the ICO guidance linked above. See §40.
- Not independently tested: Live Jev inference outputs, actual account-specific limits, SDK behaviour in a running project, independently reproduced benchmark claims, and any organisation's contractual/security configuration. Syntactically valid examples do not replace integration testing.
- On future updates: Check the TypeSafe documentation index, then the Models page and the relevant SDK, API, jaggedness and legal pages. Record the verification date, affected sections and model version; revalidate risk thresholds and decision behaviour before upgrading a production deployment.
It is a pleasure to share good things