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-9B + diffusion drafterJeeves
A 9B Jev-style decision model with an optional reasoning stage, published weights, training code and data, plus a compatible local API.
Community model
Qwen3.5-4BOpenJev-4B
A 4B open-vocabulary probabilistic decision model with published weights, two-stage training code, local inference and an HTTP service.
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.
Community model
Qwen3-0.6BNanoJev
A small model with decision heads, published training code, and game demos for testing action choices.
Community model
Qwen3.5-2Bdecider
A fine-tuned model that returns distributions for typed questions in one pass. Its current release supports English.
Community model
ModernBERT 151M / Verdict 2.0Verdict
A small encoder-based decision model with published weights and an in-browser WebGPU demo.
Community 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.
Interface 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.
Interface 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.
Interface 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.
Interface 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.
Interface 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.
Community model
Qwen3-0.6BAgentJev
A Qwen3-0.6B decision model for agent traces and other structured questions, with published weights, a typed HTTP API and no token decoding.
Interface experiment
Causal LMs / SGLangLLM2Jev
Adapts local causal language models into Jev-compatible Choice, Score and Noul services through prefill-only scoring, with SGLang, Transformers and multimodal support.
Interface experiment
Laya / ONNX RuntimeLaya
Runs the open Laya System One model from Node.js through ONNX Runtime, using a Jev-compatible request shape and published model weights.
Community model
Qwen3.5-0.8BOpenThai System One
A Qwen3.5-0.8B Thai-and-English decision model with published weights, training code and a Jev-compatible HTTP API.
Community model
Qwen3.5-0.8B / 2BValen
A multimodal decision model inspired by Jev that accepts text, images and video, with published weights, training code and evaluation commands.
Community model
Qwen3.5-4BTev1
An open 4B decision model fine-tuned from Qwen3.5, with model weights, a reproducible training recipe and documented data provenance.
Interface experiment
Open decision modelsOllaya
A local Rust service that downloads and runs several open decision models behind native and TypeSafe-compatible APIs.
Community model
Qwen3.5-0.8B / 2B / 4BIntern-Decision
A multimodal Qwen3.5 decision-model family with 0.8B, 2B and 4B checkpoints, published weights, training and inference code, calibration benchmarks and a Jev-compatible API.
Community model
Qwen3.5-4BMica
An English-and-Korean 4B decision model with published weights and quantizations, calibrated probabilities, and a TypeSafe-compatible local server.
Community model
Qwen3.5-0.8B / 2BJev-Style
A family of local 0.8B and 2B decision models with published weights, long-context support, a compatible API, agent skills, MCP tools and evaluation commands.
Community model
Qwen3.5-2B / 9B · Qwen3.8-27BOpen-Jev
An independent implementation with published 2B, 9B and 27B weights, training code, a compatible local server and reproducible evaluations.
Community model
Qwen3.5-VL 2B / 4B / 9Bimajev
An open 2B, 4B and 9B multimodal decision-model family for text and images, with calibrated probabilities, abstention, published weights and a compatible local API.
Community model
0.6B / 0.8B / 4B decision modelsOpenDecider
Small open models for Choice, Score and Noul decisions, with published weights and local inference on CPU, NVIDIA GPUs and Apple Silicon.
Community model
Qwen3.5-0.8B / 4Bjiwo
Open 0.8B and 4B Qwen3.5 decision models with published weights, training code, a Jev-compatible local API and reproducible Decision Index results.
Community model
Qwen3.5-0.8B / 4BSearchJev
Open 0.8B and 4B Qwen3.5 models trained for search-agent decisions, with data, weights, training logs and calibration code published.
Interface experiment
Cloudflare Clef 27B / 9Bcleffa
A native C and Metal runtime for Cloudflare Clef and Clef-Flash on Apple Silicon, serving text, image and video decisions through a Jev-compatible API.
Community model
mmBERT 144.3MPhocinae Largha
A bilingual 144.3M encoder decision model for typed local decisions, with weights, calibration tools, evaluations and a Jev-compatible server.
Community model
Multilingual Laya checkpointsLaya Decision Engine
A multilingual, non-autoregressive decision engine with public checkpoints, training and fine-tuning code, typed decisions and compatible local APIs.
Community model
Qwen3.5-0.8B / 4BVegaML
A local multimodal decision engine built on frozen Qwen3.5 backbones and a small trainable physics module, with public 0.8B and 4B checkpoints.
Interface experiment
Laya / ONNX Runtime Javalaya-java
A pure-Java runtime for Laya checkpoints with Spring Boot and Gradle integrations plus Jev- and OpenAI-compatible decision endpoints.
Community model
Qwen3.5-4B / Qwen3.8-27Btrain-jev
A framework for distilling and training Jev-style decision models on Qwen3.5 or Qwen3.8, with calibration, evaluation and compatible serving code.
Community model
LLM-jp 4.1 8B / encoder 310Msaihai
A Japanese typed decision-model family with open 8B and 310M weights, training and evaluation code, GGUF serving and a System One-compatible API.
Interface experiment
Any llama.cpp GGUFCallosum
Adds a System One API and reserved classification lanes to an existing llama.cpp chat model, with optional calibration and bounded reasoning without loading a second model.
Community model
Qwen3-VL-4BOpenVisualJev
A Qwen3-VL-4B multimodal decision model with dynamic candidate scoring, permutation-equivariant choices, calibration code and a technical report; checkpoint downloads are still pending.
Community model
BitNet b1.58 2BBitSOne-s1
A 2B ternary BitNet-based decision model with a pointer head, typed probabilities, reproducible training records and measured calibration; published checkpoint access is currently private.
Interface experiment
Open ONNX decision modelsdecision-toolkit
Runs a curated set of open decision models locally on CPU through ONNX, exposing one typed library, CLI, REST and System One-compatible API.
Community model
Qwen3-VL-4BFovea
An open 4B vision decision model with published weights, training and calibration code, served through the TypeSafe System One API.
Interface experiment
Open decision model familiesFlide
A local runtime that accelerates open decision models with exact state forking and serves multiple text and multimodal families through one interface.
Community model
Multilingual encoder 57M / ONNXSkejja
A 57M multilingual encoder model for Choice, Noul and Score decisions, with ONNX inference, browser and Raspberry Pi demos, and a compatible System One API.
Community model
Qwen3.5-9B LoRA / GGUFOpenChoice-9B
A CPU-first 9B multimodal decision model distributed as GGUF, with Choice, Score and Noul endpoints, a TypeSafe-compatible API and a LoRA fine-tuning kit.
Independent community work, not official Jev releases.
Track new community models and interface experiments in Jev AI Radar.Explore Jev AI Radar
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.