What is Jev? The System One Model for Code Decisions

Unlike large language models (LLMs) optimized for autoregressive text generation or conversational interaction, Jev is designed to ingest unstructured data and return schema-validated, probabilistic outputs. These outputs include discrete categories, calibrated scores, and binary probabilities, allowing engineers to integrate machine intelligence directly into application control flows.

In modern software architecture, Jev functions as a "smart if statement." While traditional code branches on deterministic values (such as if (user.balance > 100)), it has historically struggled with semantic judgments, such as identifying a support ticket's intent or evaluating the risk of a shell command. Jev bridges this gap by allowing engineers to define possible answers upfront, retrieve calibrated probabilities for each, and branch the application logic based on the model's judgment.

The system uses a specialized stack featuring a hardware-aware parallel sampler and a training methodology known as Reinforcement Learning for Calibrated Decisions (RLCD). This makes Jev a core architectural component for background tasks, real-time interfaces, and automated pipelines where a single judgment determines the next execution path.

Why Jev and System One models exist

The development of Jev is rooted in the distinction between System 1 and System 2 intelligence, a framework popularized by Daniel Kahneman. System 1 represents fast, intuitive judgment, whereas System 2 involves slow, deliberate reasoning. Frontier LLMs like GPT-4 or Claude are fundamentally System 2 models; they are optimized for complex reasoning and multi-step generation. However, because they are autoregressive, they generate one token at a time, introducing linear latency and high compute costs that make them inefficient for simple classification or branching logic.

Jev is built for the "Thinking Fast" category. It provides the semantic "common sense" required to interpret unstructured text without the overhead of a generative engine.

The economics of intelligence: Jevons paradox

The system is named after William Stanley Jevons, who observed that as the efficiency of a resource increases, the rate of consumption of that resource rises as new use cases open up. TypeSafe AI applies this to intelligence: by reducing the cost of a decision to a fraction of a cent and the latency to sub-100ms, software will begin to run AI judgments in millions of background tasks (including event logging, semantic linting, and real-time permission checks) where it was previously cost-prohibitive to call a generative LLM.

Technical specifications

Jev is engineered for production-grade reliability and high-throughput environments:

• Price Point: $0.042 per million input tokens ($42 per billion). Output tokens are free because the model returns structured data distributions rather than generated prose.
• Latency: End-to-end response times range from 70ms to 500ms, with a median of approximately 100ms.
• Throughput: Rate limits are approximately 250,000 tokens per second and 1,200 requests per minute.
• Context Window: Supports up to 64,000 tokens, with a limit of 32,000 tokens for the state plus the longest single question.

The problem with LLMs for decisions

Using generative models for simple branching is an architectural mismatch. LLMs are trained via Reinforcement Learning from Human Feedback (RLHF) to produce responses that humans find pleasing, which often results in verbosity and "overconfidence." For software automation, these traits are bugs. Furthermore, retrieving structured data from an LLM requires the model to generate a JSON string token-by-token. This process is prone to type errors, hallucinations, and parsing failures. Jev eliminates these risks by sampling answers in parallel and enforcing structural type-safety by construction.

The three core primitives: Choice, Score, and Noul

Every query to Jev is constructed using three primitives that define the shape of the judgment and the resulting data schema.

Noul (Yes/No)

The Noul primitive is used for binary judgments. It returns a single probability value between 0 and 1.

• Probability as Signal: A value of 0.93 indicates a high probability of "yes," while 0.5 represents maximum uncertainty.
• No Confidence Field: Unlike Choice or Score, Noul lacks a separate confidence field because the probability value itself is the signal of uncertainty.

// Request
{
  "refund_requested": {
    "type": "noul",
    "instructions": "Does the customer ask for money back?"
  }
}
 
// Response
{
  "refund_requested": {
    "type": "noul",
    "noul": 0.93
  }
}

Choice (pick one)

Choice is used when the answer must be selected from a fixed set of up to 255 non-ordered options.

• Output: Returns the selected option (choice), the full probability distribution (probabilities), and a confidence score.
• Confidence Calculation: This score reflects how "peaked" the distribution is. If the probability is concentrated on one option, confidence is high. If it is spread evenly, confidence is low.

Score (spectrum/rubric)

The Score primitive measures a position on an ordered spectrum with 2 to 10 levels.

• Weighted Mean Calculation: The returned score is a probability-weighted mean of the level indices (starting at 0). For example, if level 1 has a 0.1 probability and level 2 has a 0.9 probability, the score is (1 × 0.1) + (2 × 0.9) = 1.9.
• Architectural Advice: Do not use Scores to measure subjective degrees (such as "Moderately Severe"). Instead, describe specific situations. A level like "Broken feature, but a workaround exists" gives the model a concrete situational match, whereas subjective adjectives lead to spread distributions and low confidence.

Speculative fan-out and parallel evaluation

A primary technical differentiator for Jev is the ability to evaluate multiple independent questions against a single state simultaneously, a pattern known as speculative fan-out.

Parallel sampling vs. autoregressive bottlenecks

Traditional LLMs generate tokens autoregressively; each token is conditioned on the previous one. This creates a sequential bottleneck where Question B cannot be answered until Question A has been fully generated. Jev trades string generation for parallel sampling. It evaluates every question independently against the provided state. This hardware-aware approach ensures that adding questions does not linearly increase latency.

Efficiency gains

In production benchmarks, a request containing 13 questions was 12.2x cheaper and 10x faster than 13 sequential LLM calls. Because the state (the heavy payload) is only sent once, the token overhead is minimized. Internal testing shows that batching has no effect on accuracy beyond normal sampling noise; engineers are encouraged to ask every question they might conditionally need in a single call.

Context isolation

Because questions are evaluated independently, the result of one question never biases another within the same call. This prevents "context contamination," a common failure mode in LLM prompting where the model's first answer influences its subsequent logic.

Understanding confidence and the three-tier routing pattern

Jev uses Reinforcement Learning for Calibrated Decisions (RLCD). In a calibrated model, a 90% probability means the model should be correct approximately 90% of the time across a large dataset. This epistemic honesty allows for reliable automation using a three-tier routing pattern:

1. High Confidence (> 0.9): Act automatically. Execute destructive actions (such as cancelling an order) or high-stakes logic without human intervention.
2. Medium Confidence (0.5–0.9): Flag for review or ask for user confirmation (e.g., "It looks like you want to cancel; is that correct?").
3. Low Confidence (< 0.5): Route to a human agent or a slower System 2 model. The model is signaling genuine uncertainty.

Risk Invariants: These thresholds must live in the application code, not the model. High-risk actions require higher confidence floors. Engineers must also account for the invariant that P(noul) and 1 - P(not noul) are independent probabilities and are not guaranteed to sum to 1.0.

The "smart if statement": How to architect applications with Jev

Architecting with Jev requires shifting logic out of the prompt and back into the codebase.

TypeScript implementation

Using the official SDK, you can triage tickets with a single call:

import { choice, noul, score, TypeSafeClient } from "@typesafe-ai/sdk";
 
const client = new TypeSafeClient();
const ticket = "The export button crashes in Safari. Works in Chrome.";
 
const { answers } = await client.systemOne({
  state: { ticket },
  questions: {
    category: choice("What kind of ticket is this?", {
      bug: "Something is broken",
      billing: "Charges and invoices",
      other: null,
    }),
    severity: score("How severe is the issue?", [
      "Cosmetic",
      "Degraded but workaround exists",
      "Blocking",
    ]),
  },
});
 
if (answers.category.choice === "bug" && answers.severity.score > 1.5) {
  // Route to engineering with priority
}

Vercel AI SDK integration

For teams using the Vercel AI SDK, Jev is integrated via experimental_evaluate. Note that the vocabulary shifts slightly: noul becomes boolean and its answer field is probability.

import { experimental_evaluate as evaluate } from "ai";
import { typeSafeAi } from "@ai-sdk/typesafe-ai";
 
const result = await evaluate({
  model: typeSafeAi.evaluationModel("jev-latest"),
  state: { message: "Refund requested for order A-1." },
  questions: {
    is_refund: { type: "boolean", instructions: "Is a refund requested?" },
  },
  providerOptions: {
    gateway: { zeroDataRetention: true },
  },
});
 
// Access confidence via metadata
const confidence = result.providerMetadata.typesafe.confidence.is_refund;

Advanced architectural patterns

• Intent Routing: Deploy Jev as a high-speed router at the edge to decide if a request needs a database lookup, a generative LLM, or a person.
• Composite Scoring: Combine multiple Jev scores using weighted coefficients in code: Priority = (0.6 * severity) + (0.3 * frustration). Tuning the system requires changing numeric coefficients in code, not re-writing prompts.
• Semantic Search (Oko Pattern): Use Jev to re-rank keyword search results. A cheap keyword pass finds candidates, then Jev scores them for intent. This pattern has been shown to put the correct file first 12–38% faster than traditional embeddings.

Model jaggedness: Where Jev fails and what to keep in code

"Jaggedness" refers to the uneven distribution of a model's capabilities. For jev-1.13, engineers must guard against specific failure modes:

• Literal Reading: Jev lacks intent-reading; it reads instructions literally. If boundary conditions aren't specified, Jev will not infer them.
• Arithmetic and Counting: Jev is not a calculator. It cannot count occurrences in a list.
  • Correction: Iterate through the list in code, ask a Noul per item ("Is this a fruit?"), and sum the results in code.
• Numeric and Hex Representations: Jev struggles with Hex values (e.g., #FF4B0A) compared to English names.
  • Correction: Perform semantic bucket conversion in code (such as mapping hex to "Red") before calling the model.
• Dates and Time: Jev reads dates as text, not ordered quantities.
  • Correction: Use Choice to extract Month, Day, and Year, then construct a native Date object for comparison in code.
• Context Rot: Accuracy degrades as the state fills with irrelevant detail. High-performance systems should filter the state in code, sending only the fields required for the specific questions.

When to reach for Jev over a generative LLM

The decision to use Jev versus a generative model depends on whether the task is one of generation or judgment.

Economic and production impact

Consider a production environment spending $10,000/month on LLM costs for automation. I have seen teams spend the bulk of that budget on simple classification and input verification (System One tasks). Routing roughly 60% of those calls to Jev can reduce total monthly spend by over 50%.

Production reports indicate that candidate searches moved from minutes to seconds (a 10x speed improvement) at the same accuracy by replacing LLM-based logic with Jev judgments. Use cases like Wikiracing bots demonstrate utility in real-time, high-cardinality environments where hallucination is a non-starter.

The Architectural Rule: If the requirement is to generate text, summaries, or code, use a generative LLM. If the requirement is to "pick a card from the deck" (to classify, score, verify, or branch), use Jev.

References

• Introducing System One Models & Jev
• System One concept
• Primitives (Questions)
• Confidence
• How to build with TypeSafe
• Jev 1.13 jaggedness
• A deep dive into Jev
• Example use cases