Jev: The Cheap Judge That Can Still Cost You

Learning Objectives

• Explain what a System One model like Jev is, and how it differs from a generative LLM such as Claude
• Write Jev’s three question types (noul, choice, score) and read their typed answers, including the difference between probability and confidence
• Explain why a schema guarantees the shape of a decision but never its correctness
• Compare four placements of a judge in a coding-agent loop, and compute how a hard gate caps end-to-end recall
• Design a shadow-mode rollout that earns a judge its authority one region at a time
• Wire Jev into Claude Code as an advisory hook that can never block the agent

Prerequisites: M05 (tool use), M18 (evaluation). M22C (quality gates) and M26 (hooks) help with the last two sections.  |  Level: Intermediate

What Jev Is — A Model That Decides Instead of Writes

The published characteristics

The Three Question Types

Each question you send to Jev has an id you choose, a type, some instructions, and usually some criteria. Jev evaluates every question independently and in parallel. Adding a question never changes the answer to another one.

A real response for the three questions this module uses throughout looks like this:

This is the lab’s replay response for test F10, with the legend abridged. It follows the documented response shape, but the numbers are synthetic, not a recorded Jev response. A live response names a real model version, such as jev-1.13.0.

Probability vs. confidence: two different numbers

These are easy to mix up, and the policy code later depends on keeping them apart.

• Probability is about one outcome. "flaky": 0.84 means Jev puts 84% on “flaky”.
• Confidence is about the whole distribution: how concentrated it is, from 0 to 1. TypeSafe says it is derived from the probabilities but does not publish the formula. Two answers can both pick “flaky” at 0.84 and still differ in confidence, depending on how the remaining 16% is spread.
• Score is a probability-weighted mean. In the example it is 0.55: between Low (0) and Medium (1), leaning Low. It is not a class label, so read probabilities if you need one.

Vercel’s guide adds a practical wrinkle: probabilities are rounded, so a distribution can sum to 0.99. Never check sum == 1.

Writing good questions

The Vercel guide gives three rules, and all three apply here:

1. Ask atomic questions, ones a person could answer in seconds. Combine the answers in code, not in the question.
2. Describe options; don’t just label them. “The diff plausibly causes the observed failure” gives the model far more to work with than “yes”.
3. Send only the relevant state. Every token of state is billed and dilutes the evidence. A diff hunkOne contiguous block of changed lines in a diff, with a few lines of context around it. Sending only the hunk that touches the failing code keeps the state small and on topic. beats the whole diff.

“Typed” Prevents Malformed Answers, Not Wrong Ones

TypeSafe markets Jev as a model that “can’t hallucinate”. That is true in a narrow and useful sense. If a question allows only regression, flaky, environment and unknown, Jev cannot invent a fifth category, wrap its answer in an apology, or return JSON your parser chokes on. A whole class of production bugs goes away: the ones where a generative model answers "Probably flaky, but…" and your if statement never matches.

What typing cannot do is make the chosen category correct. Jev can pick flaky, a perfectly valid option, for a test that fails because the diff removed a lock. Vercel’s guide says it plainly: the schema constrains the answers but doesn’t guarantee they’re correct. Arize’s independent analysis makes the same distinction: a schema-correct classification can still be wrong.

This matters because of what happens after the wrong answer. If Jev’s answer is one signal among several, a wrong answer is a weak signal that other checks can outvote. If Jev’s answer decides whether Claude ever sees the failure, a wrong “flaky” means the stronger model never gets the chance to catch it.

Where Jev Sits in a Build → Verify → Fix Loop

A coding agent like Claude Code works in a loop: edit the code, run the checks, read what failed, fix it, check again. The tempting design drops Jev into the middle. Deterministic tools run, Jev cheaply screens whatever fails, and Claude only investigates what Jev considers important.

The order of the stages is the most important design decision in this module. Compilers, linters, type checkers, test runners, security scanners and invariant checks come first, and they stay authoritative wherever they can give a deterministic verdict. A type error is a type error; no model should be asked to “judge” it. Jev belongs after those tools, working on the evidence they produce, never in their place. And the step after Jev is not Claude directly but policy code: ordinary, testable code that turns Jev’s numbers into an action.

Four Architectures, Four Different Costs of Being Wrong

Why a hard gate caps the whole pipeline

RecallOf all the real regressions, the share that got caught. 90% recall means 1 real regression in 10 slipped through. is the share of real regressions that get caught. With a hard gate in front, a regression is caught only if both stages catch it: the gate has to pass it and the agent has to recognise it. Ignoring correlated errors, the probabilities multiply:

That example is illustrative, not a Jev benchmark. The point it makes is structural. The 97%-capable downstream model didn’t get worse. The system got worse, because 10% of the real regressions never reached it. The gate’s recall is a ceiling on everything after it. Drag the sliders to see how fast that ceiling bites:

The same 24 failures, two placements

This is the lab’s data: 24 CI failures from a fictional order-tracking service, 10 of them real regressions. The Jev answers are the lab’s synthetic fixtures. Watch where each failure lands, especially F10, a release-blocking race condition that Jev reads as flaky.

Under the hard gate, Claude sees 9 failures and the pipeline catches 7 of the 10 regressions: 70%. The uncertainty router sends Jev’s unsure cases to Claude and reruns its confident “flaky” and “environment” cases, escalating any rerun that fails again. F10’s rerun fails, so it reaches Claude. The router catches 9 of 10, the same as sending everything to Claude, with 14 Claude calls instead of 24.

The soft prioritizer deserves one warning. It keeps everything visible, so on paper its recall equals the baseline. But if the queue is cut at the same 9 items the gate allowed, because the reviewer ran out of time, it catches exactly what the gate caught. A queue nobody drains is a gate with extra steps.

Optimise expected total cost, not the API bill

If the workflow processes 10,000 items and one false negative can ship a serious regression, saving a few thousand model calls is not automatically an improvement. In the lab, with illustrative costs of $5,000 for a missed high-severity regression and $500 for a medium one, the hard gate saves $0.035 in API calls and adds $5,500 in expected losses.

What the Published Numbers Actually Show

Ben Greenberg: Jev vs. Claude on one bounded decision

Greenberg took 102 archived submissions and ran each one three times, for 306 decisions. Every decision applied a fixed policy to an evidence packet and picked one of three states: satisfied, not satisfied, or insufficient evidence. The post reports:

• Accuracy: Jev scored 100.0% with a choice question plus four diagnostic noul questions. Claude Sonnet 5 with high reasoning scored 99.0%. Jev’s choice question on its own made 2 errors in 306. Rebuilding the policy in code from the four nouls did worst, at 94.1%.
• Median latency: 378 ms for Jev, 3,554 ms for Sonnet
• Cost per 10,000 evaluations: about $2.27 vs. $129.74, roughly 57×
• Expected Calibration Error (ECE)How far a model’s stated confidence is from its actual accuracy, averaged across confidence levels. 0 is perfectly calibrated; lower is better.: 0.037 for Jev vs. 0.058 for Sonnet. Sonnet’s few errors sat in its 0.9–1.0 confidence band. Both of the choice-only Jev errors sat at 0.2–0.3.

Two lessons come out of this for system design. First, a policy hand-assembled from several signals is not automatically better than a well-posed single question; the hand-built one was the weakest setup in the post. Keep policy code simple, and measure it like everything else.

Second, and most useful, is calibration. An error made at 0.25 confidence can be routed to review. An error made at 0.95 confidence goes straight through any threshold. Greenberg calls his setup “a deliberately unfair place to make a sweeping model comparison”, and notes that Jev does not replace the parts of his workflow that need code analysis and written explanations.

Arize: Jev as an LLM-as-judge replacement

Arize compared Jev with LLM judgesAlso called LLM-as-judge: using a general-purpose language model to grade or classify another system’s output, usually with a rubric in the prompt and an explanation in the reply. Covered in M18. on hallucination detection. As summarised in its published write-up, Jev matched Claude Opus 5 at 87% accuracy on a held-out set after each judge’s decision threshold was tuned, at roughly 1/300 of the cost and 23× the speed. Arize describes the evidence as promising but early and task-dependent. It also names the biggest loss: Jev gives no explanation, so its suggested pattern is to run Jev on every trace and re-run a sample of the failures through an LLM judge for the reasoning.

A Runnable Screening Layer

One function sends a failing test’s evidence to Jev and returns one of three actions. The Python and Node.js tabs call the native REST API directly. The third tab shows the same logic through the Vercel AI SDK, which is the form the source article uses, so you can see the naming differences side by side.

1. Chunk 1, the questions. What: three atomic questions: a noul, a four-way choice that includes unknown, and a three-level score. Why: the unknown option gives Jev an honest way to say “not enough evidence” instead of forcing a guess into another bucket. Gotcha: the criteria are sentences, not labels. “The failure is probably flaky, environmental, or unrelated” is a much better “false” than “no”.
2. Chunk 2, the call. What: one POST with a bearer token and a 10-second timeout, retrying only on 429 (rate limited) and 529 (overloaded). Why: those are the two statuses TypeSafe documents as retryable. A 422 is your bug, and retrying it just burns time. Gotcha: in Node, fetch has no timeout of its own, hence AbortSignal.timeout().
3. Chunk 3, failing toward scrutiny. What: any Jev failure (network, auth, timeout) returns review-ambiguous-case. Why: a judge that is down must never turn into a judge that says “fine”. Gotcha: a bare except: return "rerun" here would silently turn every Jev outage into suppressed failures.
4. Chunk 4, the policy. What: three thresholds on three different numbers: regression probability, choice confidence, and the chosen option’s probability. Why: the policy lives in code, where you can read it, test it and version it. Gotcha: the thresholds are examples. A security gate, a flaky-test router and a docs scorer need different cutoffs, chosen from labelled cases like your own.

"""Screen one failing CI test with Jev. Python 3.10+; pip install "httpx>=0.27"; export TYPESAFE_API_KEY=..."""
import os
import time

import httpx

API_URL = "https://api.typesafe.ai/v1/systemone"
MODEL = "jev-latest"  # pin e.g. "jev-1.13.0" once your thresholds are tuned against it

# --- Chunk 1: atomic questions; criteria DESCRIBE each option ---
QUESTIONS = {
    "is_regression": {
        "type": "noul",
        "instructions": "Did the current code change probably cause this test failure?",
        "criteria": {"true": "The diff plausibly causes the observed failure.",
                     "false": "The failure is probably flaky, environmental, or unrelated to the diff."},
    },
    "failure_type": {
        "type": "choice",
        "instructions": "What best explains this failure?",
        "criteria": {"regression": "The current diff introduced a product defect.",
                     "flaky": "The test is nondeterministic or timing-sensitive.",
                     "environment": "Infrastructure or configuration caused the failure.",
                     "unknown": "The evidence is insufficient to choose another category."},
    },
    "severity": {
        "type": "score",
        "instructions": "How strongly should this failure block the change?",
        "criteria": ["Low: non-blocking or clearly unrelated",
                     "Medium: plausible issue requiring more evidence",
                     "High: likely release-blocking regression"],
    },
}


class JevError(RuntimeError):
    pass


# --- Chunk 2: one call, retry only what the API says is retryable ---
def ask_jev(state: dict, attempts: int = 3) -> dict:
    key = os.environ.get("TYPESAFE_API_KEY")
    if not key:
        raise JevError("TYPESAFE_API_KEY is not set")
    body = {"model": MODEL, "state": state, "questions": QUESTIONS}
    for attempt in range(1, attempts + 1):
        try:
            r = httpx.post(API_URL, json=body, timeout=10.0,
                           headers={"Authorization": f"Bearer {key}"})
        except httpx.HTTPError as e:
            if attempt == attempts:
                raise JevError(f"network error: {e}") from e
        else:
            if r.status_code == 200:
                return r.json()["answers"]
            if r.status_code not in (429, 529) or attempt == attempts:
                raise JevError(f"HTTP {r.status_code}: {r.text[:200]}")
        time.sleep(0.5 * 2 ** attempt)
    raise JevError("unreachable")


def route(state: dict) -> str:
    # --- Chunk 3: a judge that is down fails toward MORE scrutiny ---
    try:
        a = ask_jev(state)
    except JevError as e:
        print(f"[jev] unavailable, escalating: {e}")
        return "review-ambiguous-case"

    # --- Chunk 4: policy in code. EXAMPLE thresholds -- tune on your own labelled cases ---
    p_reg = a["is_regression"]["noul"]
    ft = a["failure_type"]
    type_prob = ft["probabilities"].get(ft["choice"], 0.0)
    if p_reg >= 0.75 and ft.get("confidence", 0.0) >= 0.60 and type_prob >= 0.70:
        return "investigate-with-claude"
    if p_reg <= 0.20 and ft["choice"] in ("flaky", "environment") and type_prob >= 0.75:
        return "rerun-and-collect-evidence"
    return "review-ambiguous-case"


if __name__ == "__main__":
    failure = {
        "testName": "test_sla_credit_concurrent_updates",
        "stdout": "FAILED tests/test_sla.py::test_sla_credit_concurrent_updates\n"
                  "assert po.credit_total == 2\n  where po.credit_total = 4",
        "stderr": "",
        "diffHunk": "-    with po_lock(po.id):\n-        apply_credit(po)\n+    apply_credit(po)",
        "recentRuns": [{"passed": True, "commit": "a41c"}, {"passed": False, "commit": "b7e2"}],
    }
    print(route(failure))

// Screen one failing CI test with Jev. Node 18+ (built-in fetch). TYPESAFE_API_KEY=... node screen.mjs
const API_URL = "https://api.typesafe.ai/v1/systemone";
const MODEL = "jev-latest"; // pin e.g. "jev-1.13.0" once your thresholds are tuned against it

// --- Chunk 1: atomic questions; criteria DESCRIBE each option ---
const QUESTIONS = {
  is_regression: {
    type: "noul",
    instructions: "Did the current code change probably cause this test failure?",
    criteria: {
      true: "The diff plausibly causes the observed failure.",
      false: "The failure is probably flaky, environmental, or unrelated to the diff.",
    },
  },
  failure_type: {
    type: "choice",
    instructions: "What best explains this failure?",
    criteria: {
      regression: "The current diff introduced a product defect.",
      flaky: "The test is nondeterministic or timing-sensitive.",
      environment: "Infrastructure or configuration caused the failure.",
      unknown: "The evidence is insufficient to choose another category.",
    },
  },
  severity: {
    type: "score",
    instructions: "How strongly should this failure block the change?",
    criteria: [
      "Low: non-blocking or clearly unrelated",
      "Medium: plausible issue requiring more evidence",
      "High: likely release-blocking regression",
    ],
  },
};

class JevError extends Error {}
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

// --- Chunk 2: one call, retry only what the API says is retryable ---
async function askJev(state, attempts = 3) {
  const key = process.env.TYPESAFE_API_KEY;
  if (!key) throw new JevError("TYPESAFE_API_KEY is not set");
  for (let attempt = 1; attempt <= attempts; attempt++) {
    let r;
    try {
      r = await fetch(API_URL, {
        method: "POST",
        headers: { Authorization: `Bearer ${key}`, "Content-Type": "application/json" },
        body: JSON.stringify({ model: MODEL, state, questions: QUESTIONS }),
        signal: AbortSignal.timeout(10_000), // fetch has no timeout of its own
      });
    } catch (e) {
      if (attempt === attempts) throw new JevError(`network error: ${e.message}`);
    }
    if (r) {
      if (r.status === 200) return (await r.json()).answers;
      if (![429, 529].includes(r.status) || attempt === attempts) {
        throw new JevError(`HTTP ${r.status}: ${(await r.text()).slice(0, 200)}`);
      }
    }
    await sleep(500 * 2 ** attempt);
  }
  throw new JevError("unreachable");
}

export async function route(state) {
  // --- Chunk 3: a judge that is down fails toward MORE scrutiny ---
  let a;
  try {
    a = await askJev(state);
  } catch (e) {
    if (!(e instanceof JevError)) throw e;
    console.error(`[jev] unavailable, escalating: ${e.message}`);
    return "review-ambiguous-case";
  }
  // --- Chunk 4: policy in code. EXAMPLE thresholds -- tune on your own labelled cases ---
  const pReg = a.is_regression.noul;
  const ft = a.failure_type;
  const typeProb = ft.probabilities?.[ft.choice] ?? 0;
  if (pReg >= 0.75 && (ft.confidence ?? 0) >= 0.6 && typeProb >= 0.7) return "investigate-with-claude";
  if (pReg <= 0.2 && ["flaky", "environment"].includes(ft.choice) && typeProb >= 0.75) {
    return "rerun-and-collect-evidence";
  }
  return "review-ambiguous-case";
}

const failure = {
  testName: "test_sla_credit_concurrent_updates",
  stdout: "FAILED tests/test_sla.py::test_sla_credit_concurrent_updates\nassert po.credit_total == 2\n  where po.credit_total = 4",
  stderr: "",
  diffHunk: "-    with po_lock(po.id):\n-        apply_credit(po)\n+    apply_credit(po)",
  recentRuns: [{ passed: true, commit: "a41c" }, { passed: false, commit: "b7e2" }],
};
console.log(await route(failure));

// Same policy through the Vercel AI SDK (ai >= 7.0.105) and Vercel AI Gateway.
// npm i ai ; vercel link && vercel env pull   (local OIDC tokens expire after 12h -- re-pull on 401)
// NOTE the different vocabulary: "boolean" not "noul", .probability not .noul,
// confidence under providerMetadata, model id "typesafe-ai/jev".
import { experimental_evaluate as evaluate } from "ai";

export async function route(failure) {
  let result;
  try {
    result = await evaluate({
      model: "typesafe-ai/jev",
      state: failure,
      questions: {
        isRegression: {
          type: "boolean",
          instructions: "Did the current code change probably cause this test failure?",
          criteria: {
            true: "The diff plausibly causes the observed failure.",
            false: "The failure is probably flaky, environmental, or unrelated to the diff.",
          },
        },
        failureType: {
          type: "choice",
          instructions: "What best explains this failure?",
          criteria: {
            regression: "The current diff introduced a product defect.",
            flaky: "The test is nondeterministic or timing-sensitive.",
            environment: "Infrastructure or configuration caused the failure.",
            unknown: "The evidence is insufficient to choose another category.",
          },
        },
      },
      providerOptions: { gateway: { zeroDataRetention: true } },
    });
  } catch (e) {
    console.error(`[jev] unavailable, escalating: ${e.message}`);
    return "review-ambiguous-case";
  }

  const { isRegression, failureType } = result.answers;
  const confidence = result.providerMetadata?.typesafe?.confidence?.failureType ?? 0;
  const typeProb = failureType.probabilities?.[failureType.choice] ?? 0;

  if (isRegression.probability >= 0.75 && confidence >= 0.6 && typeProb >= 0.7) {
    return "investigate-with-claude";
  }
  if (isRegression.probability <= 0.2 && ["flaky", "environment"].includes(failureType.choice) && typeProb >= 0.75) {
    return "rerun-and-collect-evidence";
  }
  return "review-ambiguous-case";
}

With the lab’s fixture for this failure (noul 0.14, flaky at 0.84, confidence 0.58), the output is:

Measure the System You Are Actually Deploying

Model accuracy alone is not enough. Before changing the loop, freeze a set of historical cases with known outcomes. Then run the complete variants against it, not just the judge:

1. Claude-only baseline: every eligible item goes straight to the current coding model.
2. Jev-only judgement: is the bounded question itself one Jev answers well?
3. Jev hard gate → Claude: only Jev-positive items reach the coding model.
4. Jev soft priority → Claude: everything stays visible, but Jev sets the order.
5. Jev uncertainty router: clear cases follow policy, and ambiguous ones escalate.
6. Cheaper general-model baseline: before adding a whole new component, try a smaller Claude tier such as Haiku 4.5 in the same position.

For every variant, capture:

• End-to-end recall and precisionOf everything the pipeline flagged as a regression, the share that really was one. Low precision means engineers waste time on false alarms., not just the judge’s standalone accuracy
• False negatives broken down by severity. One missed high-severity regression outweighs ten missed cosmetic ones.
• The percentage of items escalated to Claude
• Total input and output tokens across the whole path
• Median and p95 latencyThe latency that 95% of requests beat. The slow tail is what users and CI timeouts feel, even when the median looks fine.
• Retries, timeouts, and what happens when the model is unavailable
• Human-review volume
• The estimated cost of a missed defect, not only the API cost

The lab’s Step 3 does exactly this for four of the variants. Its output, in replay mode with recorded agent verdicts, is:

When Jev Is a Strong Fit, and When It Isn’t

Jev is most compelling when a decision is narrow, repeated, measurable and reversible:

• Classifying a failure as regression, flaky, environment or unknown
• Prioritising a large queue of test failures or review comments
• Routing clear cases while escalating uncertain ones
• Scoring evidence against an explicit rubric
• Producing typed signals for deterministic policy
• Running an eval on every trace, where an LLM judge would only be affordable on a sample

It is a weaker fit when the task needs repository-wide causal reasoning, arithmetic, multi-step investigation, weighing contradictory evidence, an explanation, or a generated fix. Those remain jobs for deterministic tools, a capable coding model such as Claude, or a human reviewer.

The Rollout to Trust: Start in Shadow Mode

Do not begin with a hard gate. Begin with shadow modeRunning a new component beside the live system on real traffic, logging what it would have done, without letting it change a single outcome. You compare its would-be decisions with what actually happened.: run Jev beside the existing workflow without changing any route. Promote it one region at a time, only when the disagreement data says it has earned that authority.

The lab’s Step 4 turns a shadow log into a recommendation for each region:

This is less dramatic than dropping a cheap judge into every step of the loop. It is also how you find out whether the new component saves money in your system, rather than merely having a low list price.

Jev Inside Claude Code: An Advisory Hook

A PostToolUse hookA command Claude Code runs after a tool call finishes. It receives the call and its result as JSON on stdin, and can reply on stdout, for example to add context for Claude or, if you choose, to block. Covered in M26. runs after every tool call. The lab ships one that watches for Bash test commands. When a test fails, it asks Jev about the failure and hands Claude one line of additionalContextA field in a hook’s JSON reply whose text is added to what Claude sees next. It informs; it does not stop or rewrite anything.. That line is phrased as a hint, and Claude still decides.

Note that the advice is wrong: this is F10 again. That is the whole design. Because the hook only advises, a wrong hint costs one sentence of context, and Claude, reading the diff, sees the removed lock. The hook deliberately never does three things:

• Block: no "decision": "block". A cheap judge must not gate the agent.
• Rewrite: no updatedToolOutput. Claude sees the real test output.
• Fail shut: if Jev is down, the hook prints nothing and exits 0.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "python \"$CLAUDE_PROJECT_DIR/labs/BONUS-jev-judge/hooks/jev_advisory_hook.py\"",
            "timeout": 15
          }
        ]
      }
    ]
  }
}

The hook itself (Python and Node.js) is in labs/BONUS-jev-judge/hooks/. For the full hook contract, see M26. For blocking gates that should block, because they are deterministic, see M22C.

Hands-On Lab: labs/BONUS-jev-judge

The lab works on 24 frozen CI failures from the fictional Northwind order-tracking service (course Domain B), in Python and Node.js. It runs free with no Jev key: without TYPESAFE_API_KEY, Jev answers come from synthetic replay fixtures in the documented response shape. Replay proves your code handles real responses. It says nothing about Jev’s accuracy, and the lab says so every time it runs.

Start with labs/BONUS-jev-judge/README.md. Everything is Tier 1: raw REST for Jev and the raw Messages API for Claude.

Knowledge Check

Module Summary

Key Concepts

• Jev is a System One model: state and typed questions in, typed answers with probabilities out. It is fast (70–500 ms) and cheap ($0.042 per 1M input tokens), and it writes no prose.
• Typed ≠ correct. The schema removes malformed answers, not wrong ones.
• Probability is not confidence. Probability is about one outcome; confidence is about the whole distribution. Good policies use both.
• Placement decides the cost of an error. A hard gate multiplies its misses into the pipeline. An uncertainty router escalates what it is unsure of and reruns before it dismisses anything.
• Measure systems, not judges. Use end-to-end recall, false negatives by severity and expected total cost on a frozen, labelled set.
• Earn authority. Go from shadow, to disagreement study, to soft priority, to uncertainty routing, to narrow automation, with a rollback at every rung.
• In Claude Code, advise; don’t gate. Jev belongs in additionalContext, never in "decision": "block".

The right question is not “Is Jev cheaper than Claude?” It is: which bounded decision should Jev own, what happens when it is uncertain, and how will you detect the cases it gets wrong?

How This Maps to the Rest of the Course

Sources and Further Reading

• Udaykiran Estari, “Jev + Claude Code: The Cheap Judge That Can Still Cost You”, Medium, September 2026. This module’s source article.
• TypeSafe AI: Introducing System One Models & Jev
• TypeSafe AI: API reference (/v1/systemone)
• Vercel: How to classify, route, and score with Jev and AI SDK
• Ben Greenberg: Jev vs Claude: Who Wins?
• Arize AI: TypeSafe Jev: Can Decision Models Replace LLM Judges?

Illustrative numbers on this page (the 0.90 × 0.97 example and every Jev answer from the lab) are labelled as such. The lab’s Jev answers are synthetic fixtures, not recordings.