Understand the state
The model interprets natural-language or structured text: a ticket, an agent trace, a product record, or a game state.
Jev AI Dev · developer guide
What is the System One AI model? A developer’s guide to Jev.
System One is TypeSafe’s AI model class for developers who need to turn unstructured application state into typed answers and probabilities. Jev is its first implementation: a bounded decision component designed to sit inside application code.
- Input
- Text, JSON, or text arrays
- Output
- Choice, Score, or Noul
- Control flow
- Owned by your code
An independent developer guide. Product details and performance statements are attributed to TypeSafe; test Jev on your own data before using it in production.
System One
state → decisionsstate
“I was charged twice and need this fixed today.”
choicebilling0.96
noulurgent0.88
scorefrustration1.7 / 2
if (confidence < threshold) → reviewThe model class
A System One model is a decision primitive for application code.
A System One model reads meaning from an input, but it does not continue the conversation or compose a response. You declare the question and allowed answer shape first; the model returns a bounded judgment your program can inspect.
Stay inside a contract
The application defines the answer space before the call. The model selects a choice, places an item on a scale, or evaluates a yes/no proposition.
Expose uncertainty
Every answer exposes a probability signal. Choice and Score also summarize the spread as confidence, helping code distinguish clear from ambiguous results.
Compose with code
Ordinary code still owns thresholds, policy checks, side effects, retries, fallbacks, and human review.
Jev in a workflow
How developers integrate Jev with application code.
Jev turns one model call into a set of decision signals. For a developer, the useful unit is not a chat turn; it is a small, typed contract between a model and an application.
1. Build the state
Send the information needed for the decision. Jev currently accepts text-based inputs, including strings, JSON objects, and arrays of text.
Customer message + account facts2. Define the questions
Name each question, choose its primitive, and describe the allowed options or scale. Several independent questions can travel in the same request.
department · urgency · frustration3. Jev evaluates them
Jev returns a typed answer and probability signal for every question. Choice and Score also include a separate confidence value.
billing · 0.93 · high confidence4. Your code applies policy
Combine the model output with deterministic checks. Act when risk is low; escalate uncertain or high-impact cases to a person or a reasoning model.
route · ask · review · stopThree answer shapes
Choice
billingWhich team should handle this?
Selects one option from a predefined set and returns a probability for every option.
Score
1.43 / 2How severe is this issue?
Places the input on a spectrum described by ordered levels; the score can fall between levels.
Noul
0.95Does this request a refund?
Evaluates a yes/no proposition and returns the model’s probability for “yes”.
The argument behind it
Why TypeSafe built a model interface for software.
Generative models are built to produce flexible strings for people. TypeSafe’s thesis is that software needs a narrower shape of intelligence: a component that can sit inside code, run repeatedly, expose uncertainty, and leave control flow visible.
Strings are powerful but open-ended
A generated answer can be prose, code, JSON, a refusal, or something malformed. Applications often need to parse, validate, and recover before acting.
Automation needs boundaries
When a model runs in the background, the program needs to know the possible outputs in advance and decide exactly which actions each output can unlock.
Uncertainty should change behavior
A probability distribution lets the workflow route clear cases automatically and send ambiguous cases to a safer path.
Small decisions should compose
Complex workflows can be decomposed into focused semantic judgments, then joined with deterministic logic instead of hidden in one large prompt.
Where it can fit
Where System One AI fits in developer workflows.
The strongest candidates occur often, require understanding messy input, and lead to a small number of actions your application already knows how to perform.
Support operations
Classify tickets, identify intent and urgency, estimate customer sentiment, and route uncertain cases for review.
Billing, technical, account, or something else?
Agent control
Choose a model or tool, decide whether retrieval is needed, judge whether a result is complete, or inspect a proposed tool call.
Can the agent continue, retry, or escalate?
Ranking and relevance
Score how well a candidate matches a query, profile, policy, or context before combining that signal with business rules.
How relevant is this candidate to the request?
Safety and verification
Evaluate messages, generated outputs, traces, or code changes against explicit criteria, with high-risk outcomes kept behind deterministic gates.
Does this violate the stated rule?
Real-time interaction
Select legal actions for games, simulations, responsive interfaces, or device automations where a long generated response would be wasteful.
Which allowed action best fits this state?
Data operations
Turn large volumes of records into categories, scores, flags, and features that downstream systems can aggregate or inspect.
Which label and risk level apply to this record?
A good fit
The choices are known, the input is semantically messy, the decision repeats, latency matters, and your code has a clear action or fallback for every result.
A poor fit
You need original prose or code, deep multi-step reasoning, broad research, an explanation, multimodal input, or a task whose possible outcomes cannot be defined in advance.
System One vs. generative LLMs
System One and generative LLMs play different roles in an AI stack.
Both approaches can understand language, and an LLM can be wrapped in a structured-output schema. The deeper distinction is what the model is designed to produce and how the surrounding software uses it.
| Aspect | Jev / System One | Common generative LLM |
|---|---|---|
| Primary job | Evaluate predefined outcomes | Generate a continuation or response |
| Native output | Typed choice, score, or yes-probability | A token sequence: prose, code, JSON, or other text |
| Answer space | Declared before the call | Open-ended, even when a schema constrains the final response |
| Uncertainty | Every answer exposes probability; Choice and Score also return confidence | May expose token probabilities or self-reported confidence; neither is usually a task-calibrated decision signal |
| Sampling | TypeSafe says questions and outputs are evaluated in parallel | Usually generated sequentially, token by token |
| Best at | High-volume semantic branching, scoring, routing, and checks | Writing, dialogue, coding, synthesis, and open-ended reasoning |
| Main failure to manage | A validly typed but semantically wrong decision | Wrong, malformed, unsupported, or off-task generated content |
| Role in a system | A bounded decision component inside visible code | A flexible generator or reasoner, often with a larger orchestration harness |
For developers evaluating System One beyond Jev, the same community module shown on the Projects page appears below. It separates independently trained models from Jev-like interfaces built on existing weights.
System One
Community System One ecosystem.
These community models and interface experiments are inspired by Jev or explore similar structured-decision approaches. They are not official TypeSafe Jev releases and are kept separate from the GitHub project ranking above.
Community model
Qwen3.5-9BBespoke Nimble
A Jev-inspired LoRA adapter and training recipe for typed choices and yes/no decisions. Runs locally; text input only.
GitHubCommunity model
Qwen3-0.6BNanoJev
A small model with decision heads, published training code, and game demos for testing action choices.
GitHubCommunity model
Qwen3.5-2Bdecider
A fine-tuned model that returns distributions for typed questions in one pass. Its current release supports English.
GitHubCommunity model
ModernBERT 151MVerdict
A small encoder-based decision model with published weights and an in-browser WebGPU demo.
GitHubCommunity model
Qwen3.5-0.8BDohnuts
A 0.8B multimodal decision model with published weights, training code, and evaluations. It handles text and images in one forward pass; its weights are for non-commercial research.
GitHubInterface experiment
DiffusionGemma 26B-A4BOpenJev
Uses the existing DiffusionGemma model to answer structured questions through a Jev-like API. It does not publish new model weights.
GitHubInterface experiment
Open-model logitsSimple Jev
Uses existing open models to score allowed answers through a Jev-like interface. It does not publish new model weights.
GitHubInterface experiment
Spark-X2.5-4BRizzo Flow
A local Jev-compatible server that reads answer logits from Spark-X2.5 models. Questions share one state prefill, and the project includes a playground and benchmarks.
GitHubInterface experiment
Any causal LLMAnyJev
A training-free toolkit that turns causal language models into typed decision models, with option-order debiasing, optional calibration, and reproducible benchmarks.
GitHubInterface experiment
Qwen3.5 / DeBERTalocal-jev
An offline Jev-compatible server for Qwen or DeBERTa models, tested with the official SDK and accompanied by published JevBench results.
GitHubIndependent community work, not official Jev releases.
Primary sources
Read the claims in context.
This Jev AI Dev guide explains TypeSafe’s framing in our own words. Use the original materials for API details, product claims, evaluation methods, and updates.
Try the shape, not just the idea
Start with one decision your application already makes.
Define the possible answers, gather representative examples, decide what uncertainty should trigger, and test Jev against your current rules or model before automating anything consequential.