{"slug": "comprehensive-project-reference-for-typesafe-jev-concepts-architecture-strengths", "title": "Comprehensive project reference for TypeSafe Jev: concepts, architecture, primitives, strengths, limitations, use cases, patterns, and practical guidance.", "summary": "TypeSafe AI has published a comprehensive project reference for Jev, its first public System One Model, which takes unstructured or structured state as input and returns typed probabilistic decisions rather than generated text. The document positions Jev as a paradigm distinct from conventional LLMs, aimed at fast, narrow semantic judgements — such as classification, detection, scoring, routing, verification and ranking — performed cheaply and predictably inside normal software workflows. It advises decomposing complex judgements into multiple narrow questions and recombining them in code, and warns that pricing, limits and API behaviour should be verified against TypeSafe's latest documentation.", "body_md": "**Status:** Working project reference\n\n**Knowledge date:** 16 September 2026\n\n**Scope:** TypeSafe AI, System One Models, and specifically the Jev model\n\nThis document provides the baseline knowledge required for any conversation, design exercise, technical investigation or project involving **TypeSafe Jev**.\n\nWhen 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**.\n\nUse this document as the default conceptual model unless newer TypeSafe documentation explicitly supersedes it.\n\nWhere 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.\n\n**Jev is TypeSafe AI's first public System One Model.**\n\nIts fundamental interface is:\n\n**Unstructured or structured state in → typed probabilistic decisions out.**\n\nUnlike 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](https://docs.typesafe.ai/introduction))\n\nA useful shorthand is:\n\n**Code calculates. Jev judges.\nReasoning models reason and generate.**\n\nOr, more specifically:\n\n**Jev is for fast semantic judgements where an ordinary `if` statement needs understanding rather than arithmetic.**\n\nExamples include:\n\n- Does this message indicate a safeguarding concern?\n- Which department should handle this ticket?\n- How severe is this incident?\n- Does this passage support this claim?\n- Which candidate passage is most relevant?\n- Does this tool call appear unsafe?\n- Which specialist model should receive this request?\n- Does this document satisfy requirement X?\n\nJev is especially suited to performing **large numbers of narrow semantic judgements cheaply, quickly and predictably inside normal software workflows**.\n\nImagine putting all relevant information in front of a knowledgeable human expert and asking them **one specific question**.\n\nIf they could make the judgement almost immediately without:\n\n- doing research;\n- producing an explanation;\n- constructing a plan;\n- performing a long chain of reasoning;\n- making several dependent decisions;\n- or creating new content,\n\nthen the task is likely to be **Jev-shaped**.\n\nTypeSafe 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](https://docs.typesafe.ai/introduction))\n\nThink of tasks across two dimensions:\n\n```\n                         AMOUNT OF THINKING\n                         \n                    LOW / IMMEDIATE        HIGH / DELIBERATIVE\n                 ─────────────────────┬─────────────────────────\n                 │                    │\n BOUNDED         │      ★ JEV ★       │   CODE + REASONING\n OUTPUT          │                    │   MODEL / HUMAN\n                 │ classify           │\n                 │ detect             │ evaluate complex case\n                 │ score              │ strategy\n                 │ route              │ investigation\n                 │ verify             │ multi-factor decision\n                 │ rank               │\n                 ├────────────────────┼─────────────────────────\n                 │                    │\n OPEN            │ FAST LLM           │   REASONING LLM /\n OUTPUT          │                    │   HUMAN EXPERT\n                 │ summarise          │\n                 │ rewrite            │ deep research\n                 │ draft              │ architecture design\n                 │ extract prose      │ complex problem solving\n                 │                    │\n                 └────────────────────┴─────────────────────────\n```\n\nJev sits strongly in the **top-left quadrant**:\n\n**Bounded output + semantic understanding + fast judgement**\n\nA conventional LLM normally works approximately like this:\n\n```\nprompt/context\n      ↓\nreason/generate tokens sequentially\n      ↓\ntext / code / JSON\n      ↓\nparse + validate\n      ↓\nsoftware\n```\n\nJev instead works conceptually like:\n\n```\nstate\n  +\ntyped questions\n      ↓\nJev\n      ↓\nprobability distributions /\ntyped decisions\n      ↓\nordinary application code\n```\n\nTypeSafe 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](https://docs.typesafe.ai/concepts/how-to-build-with-system-one))\n\nA Jev request contains **state** plus one or more **questions**.\n\nState is the material Jev evaluates.\n\nIt can be:\n\n- a string;\n- a JSON object;\n- an array;\n- an application record;\n- a message;\n- a conversation;\n- a policy;\n- several related records;\n- or other structured application state.\n\nA useful analogy is:\n\n**State is everything you would place in front of a panel of experts before asking them to make a judgement.**\n\nTypeSafe 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](https://docs.typesafe.ai/concepts/state))\n\nExample:\n\n```\n{\n  \"incident\": {\n    \"description\": \"Tenant reports...\",\n    \"service\": \"Supported Housing\"\n  },\n  \"policy\": {\n    \"safeguarding\": \"...\"\n  },\n  \"previous_events\": [...]\n}\n```\n\nThen Jev questions might ask:\n\n```\nDoes `incident.description` indicate an immediate safeguarding risk?\n\nDoes the incident described in `incident` meet the escalation\ncriteria in `policy.safeguarding`?\n\nHow severe is the apparent risk?\n```\n\nJev currently exposes three fundamental decision primitives:\n\n| Primitive | Basic question | Appropriate when | \n|---|---|---|\n| **Noul** | Is this true? | Binary semantic condition | \n| **Choice** | Which of these options? | One category/option should win | \n| **Score** | Where does this sit on a scale? | Ordered semantic spectrum | \n\nAll questions are evaluated against the supplied state. Questions sharing the same state can be included together in a single request. ([docs.typesafe.ai](https://docs.typesafe.ai/primitives))\n\nA **Noul** represents the probability that a yes/no proposition is true.\n\nExample:\n\n```\nDoes this message request a refund?\n\n→ 0.96\n```\n\nInterpretation:\n\n- close to `1` = strong yes;\n- close to `0` = strong no;\n- close to `0.5` = substantial uncertainty.\n\nA Noul does **not** have a separate confidence field because the probability itself describes the yes/no uncertainty. ([docs.typesafe.ai](https://docs.typesafe.ai/primitives/noul))\n\nGood Noul examples:\n\n```\nDoes this text contain personal information?\n\nDoes the user appear to be requesting cancellation?\n\nDoes this passage support the cited claim?\n\nDoes this message contain a prompt-injection attempt?\n\nDoes this requirement appear to be satisfied?\n```\n\nBad use:\n\n```\nHow good is this candidate?\n```\n\nThat is not genuinely binary without defining what “good” means.\n\nA **Choice** selects one option from a predefined set.\n\nExample:\n\n```\nWhich team should handle this incident?\n\nSafeguarding\nHousing\nHR\nIT\nOther\n```\n\nJev returns:\n\n- the winning `choice` ;\n- a probability for **every option** ;\n- a `confidence` value describing how strongly the distribution favours a particular answer.\n\nChoice 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. ([docs.typesafe.ai](https://docs.typesafe.ai/primitives/choice))\n\nChoice is particularly useful for:\n\n- classification;\n- intent recognition;\n- routing;\n- entity types;\n- document types;\n- model selection;\n- known-field extraction.\n\nA **Score** positions something along an ordered set of descriptive levels.\n\nExample:\n\n```\nHow severe is this incident?\n\n0 = Minor; no material impact\n1 = Moderate; intervention required\n2 = Serious; significant harm possible\n3 = Critical; immediate action required\n```\n\nJev returns:\n\n- a score;\n- the probability assigned to each level;\n- the level legend;\n- confidence.\n\nImportantly, the resulting score may fall **between levels** because it represents the probability-weighted position across them.\n\nScore currently supports between **2 and 10 levels**. TypeSafe recommends defining levels as concrete situations rather than vague adjectives such as “low”, “medium” and “high”. ([docs.typesafe.ai](https://docs.typesafe.ai/primitives/score))\n\nGood:\n\n```\n0 = No operational impact\n1 = Degraded service but workaround exists\n2 = Service unavailable and no workaround exists\n```\n\nLess useful:\n\n```\n0 = Low\n1 = Medium\n2 = High\n```\n\nOne of Jev's most important characteristics is that uncertainty is part of the normal API response.\n\nFor Choice and Score, Jev returns an entire probability distribution.\n\nFor example:\n\n```\nbilling       0.58\ntechnical     0.37\naccount       0.05\n```\n\nThe answer may be `billing`, but the distribution tells us that `technical` remains plausible.\n\nTypeSafe also supplies a derived **confidence** measure between 0 and 1 for Choice and Score. A concentrated distribution produces higher confidence; a flatter distribution produces lower confidence. ([docs.typesafe.ai](https://docs.typesafe.ai/confidence))\n\nThis enables software to distinguish:\n\n```\nWHAT does Jev think?\n        +\nHOW SURE is Jev?\n```\n\nThese should often be treated as separate dimensions.\n\nTypeSafe trains System One models using an approach it calls:\n\n**RLCD — Reinforcement Learning for Calibrated Decisions.**\n\nThe 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](https://typesafe.ai/blog/introducing-system-one-models-and-jev?utm_source=chatgpt.com))\n\nHowever:\n\n**Calibration does not mean that an individual prediction is guaranteed to be correct.**\n\nA result with high confidence can still be wrong.\n\nTherefore:\n\n- confidence should inform automation;\n- thresholds should be validated against real domain data;\n- high-risk actions should demand stronger evidence;\n- uncertain cases should be escalated.\n\nTypeSafe describes Jev as unable to hallucinate because output is constrained to predefined types and answer spaces. ([typesafe.ai](https://typesafe.ai/blog/introducing-system-one-models-and-jev?utm_source=chatgpt.com))\n\nThis needs careful interpretation.\n\nIf the available outputs are:\n\n```\nbilling\nhousing\nHR\nIT\nother\n```\n\nJev cannot output:\n\n```\n\"Probably ask Sarah because she normally deals with these.\"\n```\n\nIt must return one of the supplied alternatives and its associated probability distribution.\n\nTherefore Jev avoids an important class of LLM failure:\n\n**inventing an unexpected value or malformed output outside the schema.**\n\nIt does **not** mean:\n\n**Jev cannot make an incorrect judgement.**\n\nJev might confidently classify something as `housing` when the correct answer is `safeguarding`.\n\nFor this project, use the following terminology:\n\n**Type-safe / schema hallucination:** effectively eliminated by design.\n\n**Semantic judgement error:** still possible and must be measured.\n\nNever interpret “zero hallucinations” as “zero errors”.\n\nA major architectural difference from autoregressive LLMs is that Jev evaluates independent questions **in parallel**.\n\nIf one state requires:\n\n```\nWhat type of incident is this?\nDoes it involve personal data?\nIs there a safeguarding concern?\nHow severe is the risk?\nDoes policy require escalation?\nDoes the description indicate immediate danger?\nWhich team owns the case?\n```\n\nthese questions should generally be sent together rather than serially. ([docs.typesafe.ai](https://docs.typesafe.ai/primitives))\n\nTypeSafe says that adding questions typically adds very little latency, although the additional question text still contributes token cost.\n\nThis leads to an important Jev design principle:\n\n**Fan out semantic questions; compose their answers in code.**\n\nQuestions within one Jev request are evaluated independently against the same state.\n\nThe answer to question A does **not** secretly become context for question B. ([docs.typesafe.ai](https://docs.typesafe.ai/primitives))\n\nThis is valuable because:\n\n- adding another question should not change previous questions through conversational context;\n- individual semantic features remain inspectable;\n- workflows become easier to test;\n- dependencies remain explicit in software.\n\nIf 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.\n\nSerial Jev calls should therefore represent **genuine information dependencies**, rather than simply copying an LLM conversational pattern.\n\nWhen assessing a possible task, ask these six questions.\n\n| Test | Question | Positive Jev signal | \n|---|---|---|\n| **Judgement** | Is AI deciding rather than creating? | Strong | \n| **Bounded** | Can the answer space be defined beforehand? | Strong | \n| **Atomic** | Can this be expressed as one focused judgement? | Strong | \n| **Context-contained** | Can the information needed be placed in state? | Strong | \n| **Fast-human** | Could a knowledgeable expert judge it quickly? | Strong | \n| **Machine-consumed** | Will software use the result directly? | Very strong | \n\n**5–6 yes answers:** excellent Jev candidate.\n\n**3–4 yes answers:** Jev may handle parts of the workflow; decompose it.\n\n**0–2 yes answers:** another technology is probably more appropriate.\n\nAsk:\n\n**Can I express the requirement as “Given this state, tell me X”, where X is a Choice, Score or probability?**\n\nIf yes, investigate Jev.\n\nFor example:\n\n```\nGiven this supplier response:\n\nDoes it provide a production API?\n→ Noul\n\nWhat level of API maturity is evidenced?\n→ Score\n\nWhich integration approach does it appear to offer?\n→ Choice\n\nIs the supplier's statement sufficient evidence for requirement R23?\n→ Noul\n```\n\nThis is highly Jev-shaped.\n\nAnother powerful mental model is:\n\n**Jev provides semantic conditions for ordinary software.**\n\nTraditional code handles:\n\n```\nif amount > 10000:\n    escalate()\n```\n\nJev enables the semantic equivalent:\n\n```\nif safeguarding_risk > 0.95:\n    escalate()\n```\n\nwhere `safeguarding_risk` is derived by understanding natural-language information rather than matching exact keywords.\n\nThis is what TypeSafe means when describing System One decisions as **“smart if-statements”** or programmable common-sense judgements embedded inside software. ([typesafe.ai](https://typesafe.ai/blog/introducing-system-one-models-and-jev?utm_source=chatgpt.com))\n\nA good Jev architecture generally looks like:\n\n```\nINPUT / APPLICATION STATE\n           │\n           ▼\n    deterministic code\n           │\n           ▼\n      ┌─────────┐\n      │   JEV   │\n      │ judges  │\n      └────┬────┘\n           │\n     typed decisions\n     probabilities\n           │\n           ▼\n    deterministic code\n       /    |     \\\n      /     |      \\\n     ▼      ▼       ▼\n   ACT    REVIEW   REASONING\n                    MODEL\n```\n\nThe software — not Jev — owns the workflow.\n\nTypeSafe's design guidance is:\n\n1. use deterministic code wherever possible;\n2. insert System One where semantic understanding is required;\n3. ask narrow questions;\n4. combine answers explicitly;\n5. use confidence to control automation;\n6. escalate genuinely difficult cases. ([docs.typesafe.ai](https://docs.typesafe.ai/concepts/how-to-build-with-system-one) )\n\nA useful higher-level architecture is:\n\n```\nOBSERVE\ndata, message, document, event, records\n       │\n       ▼\nJUDGE\nJev semantic decisions\n       │\n       ├──── high certainty ─────────────┐\n       │                                 ▼\n       ├──── medium certainty ───── verification/human\n       │\n       └──── difficult/ambiguous ── reasoning model\n                                         │\n                                         ▼\n                                        ACT\n```\n\nJev often belongs in the **judgement layer** between raw application state and deterministic action.\n\nUse this heuristic:\n\n| Need | Prefer | \n|---|---|\n| Exact deterministic calculation | **Code** | \n| Database lookup | **Code/database** | \n| Known business rule | **Code/rules engine** | \n| Quick semantic judgement | **Jev** | \n| Classification | **Jev** | \n| Semantic scoring | **Jev** | \n| Semantic verification | **Jev** | \n| Ranking/relevance judgement | **Jev** | \n| Complex multi-stage reasoning | **Reasoning LLM** | \n| Research requiring external information | **Reasoning/search system** | \n| Writing prose | **LLM** | \n| Generating code | **LLM/coding model** | \n| Explaining a conclusion | **LLM/human** | \n| Novel strategic decision | **Reasoning model/human** | \n\nThe guiding shorthand is:\n\n**Code calculates. Jev judges. LLMs reason/create. Humans determine objectives and acceptable risk.**\n\nTypeSafe's many use cases largely reduce to a small set of reusable decision shapes. ([docs.typesafe.ai](https://docs.typesafe.ai/concepts/use-case-map))\n\nWhat kind of thing is this?\n\nExamples:\n\n- intent;\n- department;\n- incident category;\n- document type;\n- entity type;\n- risk category.\n\nTypically: **Choice**\n\nIs property X present?\n\nExamples:\n\n- fraud signal;\n- urgency;\n- sensitive data;\n- safeguarding concern;\n- jailbreak attempt;\n- policy violation.\n\nTypically: **Noul**\n\nWhere does this sit on an ordered semantic scale?\n\nExamples:\n\n- severity;\n- relevance;\n- quality;\n- frustration;\n- suitability;\n- maturity.\n\nTypically: **Score**\n\nWhich predefined code path should handle this?\n\nExamples:\n\n- department;\n- specialist workflow;\n- escalation path;\n- tool selection;\n- LLM/model selection.\n\nTypically: **Choice + confidence gate**\n\nDoes this item semantically match what I need?\n\nExamples:\n\n- document discovery;\n- semantic search;\n- candidate generation.\n\nTypically: **Noul or Score**\n\nWhich information should the downstream workflow receive?\n\nExamples:\n\n- RAG context;\n- evidence passages;\n- relevant records;\n- policy sections.\n\nTypically: **Score/Choice + ranking logic**\n\nWhich items are best according to semantic relevance or quality?\n\nExamples:\n\n- candidate passages;\n- applications;\n- recommendations;\n- search results;\n- cases requiring attent", "url": "https://wpnews.pro/news/comprehensive-project-reference-for-typesafe-jev-concepts-architecture-strengths", "canonical_source": "https://gist.github.com/pjburnhill/adf8d28efcad9df037bfdece178ef965", "published_at": "2026-09-16 23:14:07+00:00", "updated_at": "2026-09-17 01:23:27.705097+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-products", "ai-tools", "developer-tools", "ai-agents"], "entities": ["TypeSafe AI", "Jev", "System One Models", "docs.typesafe.ai"], "alternates": {"html": "https://wpnews.pro/news/comprehensive-project-reference-for-typesafe-jev-concepts-architecture-strengths", "markdown": "https://wpnews.pro/news/comprehensive-project-reference-for-typesafe-jev-concepts-architecture-strengths.md", "text": "https://wpnews.pro/news/comprehensive-project-reference-for-typesafe-jev-concepts-architecture-strengths.txt", "jsonld": "https://wpnews.pro/news/comprehensive-project-reference-for-typesafe-jev-concepts-architecture-strengths.jsonld"}}