what is jev?

The Jev Request and Response

The state is the evidence every question refers to. It can be a string, a JSON object or an array of text values. The questions object names each decision and defines its type, instructions and criteria. Questions in one request are evaluated independently against the same state, so one answer does not become hidden context for another.

The response keeps the question names and returns the matching answer type. Choice returns a selected option, probabilities and confidence. Score returns a probability-weighted score, level probabilities and confidence. Noul returns the probability that its yes/true condition holds. The application decides what to do with those values.

A Concrete Contract, Not a Chat Prompt

Consider a support router. The input contains the customer message and the minimum account context needed to interpret it. One Choice selects a queue; a separate Noul asks whether the customer explicitly requests a refund. Those answers are independent: the refund result cannot secretly change the queue question. If a second decision depends on the selected queue, the application makes a second request with that result represented explicitly in state.

A response preserves those question IDs and returns typed answer objects. For Choice, retain the selected criterion and the complete criterion distribution; for Noul, retain its probability. Do not reduce either to a Boolean at the storage boundary. A later threshold change, disagreement audit or calibration analysis needs the raw distribution, the pinned model ID, and the exact question and state-projection versions.

{
  "model": "jev-1.13.0",
  "state": {
    "message": "I was billed twice. Please reverse one charge today.",
    "account_plan": "team"
  },
  "questions": {
    "queue": {
      "type": "choice",
      "instructions": "Which team owns this request?",
      "criteria": {
        "billing": "Charges, invoices, refunds or payment methods",
        "technical": "Product behavior or errors",
        "other": "Neither billing nor technical"
      }
    },
    "refund_requested": {
      "type": "noul",
      "instructions": "The customer explicitly asks for a charge to be reversed"
    }
  }
}

Parallel Sampling Versus Autoregressive Generation

TypeSafe’s launch article says Jev uses a “new model architecture” and a parallel sampler rather than token-by-token generation. That supports an architectural distinction at the observable interface. It does not reveal Jev’s parameter count, layers, internal representation, serving topology, training mixture or complete RLCD recipe. A responsible architecture diagram stops at this public boundary instead of drawing an undocumented transformer or reward pipeline.

Parallel answers are not a reasoning graph. They share the same state but remain independent. Use one request when several judgments can be made from the same evidence; use application orchestration when one judgment changes the inputs or candidates for another. The primitive guide shows how several independent question types can share one state.

Why Jev Is Not Merely Structured Output

A generative LLM can be prompted to emit JSON, but it still generates a token sequence and may include an explanation or malformed value. Jev’s public interface is constrained to typed decisions and distributions. TypeSafe says its RLCD post-training objective targets calibrated decisions rather than preferred prose. That is a product and training distinction, not proof that Jev is automatically more accurate for every task.

Typed output guarantees the response shape, not the truth of the judgment. Teams still need representative labels, boundary cases, version pinning and measured thresholds. Exact validation and calculations remain better expressed as code.

A Practical Fit Test

• The answer space is bounded and can be named before inference.
• The decision requires semantic understanding rather than exact computation.
• The same decision repeats often enough that latency, cost and consistency matter.
• A real outcome or human label exists for measuring errors and calibration.
• Code can safely handle uncertainty, service failure and the eventual action.

Where Jev Belongs in an Agent, Eval and Policy Stack

This separation is why Jev evals and Jev policies are related but not interchangeable. An eval measures completed behavior and helps discover a failure pattern. A policy evaluates state before an action and changes the path. Promote an eval into a policy only after backtesting its errors, setting consequence-specific thresholds and defining service-failure behavior.

Jev evals and policies are live for Failproof AI beta users. Email nikita@befailproof.ai for access. The exact integration mechanics are intentionally not inferred here because public setup documentation does not yet define the supported hooks, mapping, timeout or billing behavior.

The Model, Provider and Runtime Are Separate Boundaries

Jev is the model family; TypeSafe’s direct API is one serving path. Cloudflare Workers AI publishes a Jev listing with its own endpoint, credentials and gateway terms. An OpenRouter Jev route page also exists, but its public models API returned no TypeSafe/Jev entry when checked September 22, 2026, so current availability is unconfirmed. A page URL alone does not prove a production route’s request contract, latency or data handling.

Pin the actual model version when thresholds matter, identify the serving provider in logs, and test the SDK or HTTP path you will deploy. The platform comparison separates places to try the model from systems that manage evaluations, while the pricing and model facts page tracks aliases and limits that can change independently of your code.

How to Read Jev Performance Claims

TypeSafe reports 70–500 ms end-to-end latency and extremely low token pricing in its launch material. The same article says evaluations were generally run from West Coast laptops near the service and notes that the short, dense state in its demo favors Jev. Those are useful first-party measurements, not a service guarantee or proof of universal superiority.

Benchmark the complete deployed path: state construction, network, provider queueing, retries, serialization and any fallback. For quality, use the same held-out labels and answer meaning across Jev, rules and an LLM judge. Report per-slice errors, calibration, coverage at the action threshold, latency distribution, cost and downstream decision impact. The Jev-versus-LLM guide explains interface differences; the Jev-as-LLM-judge comparison defines the fair experiment.

Examples

Useful examples include routing a support request to an approved team, deciding whether a passage supports a claim, rating urgency against explicit levels, selecting a skill from a filtered set, scoring a completed agent session and checking whether a proposed tool call violates a semantic policy. Jev should not count tool calls, compare dates, calculate refund amounts or generate the response itself.