Skip to documentation

Crucible

Judge governance

An LLM judge grades groundedness across chat, agents, evals, and drift scans — so a judge that quietly drifts corrupts every quality signal downstream of it. Judge governance treats the judge as a measured instrument: it is calibrated against a human-labeled gold set, scored on agreement, false-positive, and false-negative rates, and only ever swapped through a shadow cutover that proves the new judge is better before it goes live.

The calibration gold set

The gold set is a curated collection of cases with human ground-truth labels— grounded vs. ungrounded claims, correct vs. incorrect verdicts — that represents what "right" means for this workspace. It is the fixed reference every judge is measured against. Because it is human-labeled and stable, it turns "is the judge good?" from an opinion into a measurement.

The gold set is the anchor

Every metric below is defined relative to the gold set. Curate it deliberately: it should cover the hard, ambiguous, and adversarial cases, because a judge that only agrees on easy examples tells you nothing.

Agreement, FPR & FNR

Running a judge over the gold set and comparing to the human labels yields the metrics stored in judge_calibration:

  • Agreement— how often the judge's verdict matches the human label. The headline number, but not the whole story.
  • False-positive rate (FPR) — how often the judge calls something grounded that humans marked ungrounded. High FPR means the judge rubber-stamps hallucinations — the dangerous failure.
  • False-negative rate (FNR) — how often the judge flags a claim that was actually grounded. High FNR means noise: it erodes trust and buries real regressions under false alarms.

FPR and FNR trade off, and the right balance is a policy choice. For a client-facing groundedness gate you usually weight low FPR most — never vouch for an unsupported claim — while tolerating some FNR. Reporting all three keeps that trade-off explicit instead of hidden inside a single accuracy number.

Shadow-judge cutover

You never swap the live judge blind. A candidate judge — a new model, a new prompt — first runs in shadow: it grades real traffic and the gold set with results recorded to judge_runs, but with no live effect. Its metrics are compared against the current baseline, and it is promoted only if it clears the thresholds and beats the incumbent.

Judge model cutover

A measured judge cutover: shadow → compare against gold → gate → promote.

Rendering diagram

Downloads

Concepts

  • Judge governance
  • Cutover

Keywords

  • judge_runs, no live effect
  • calibration gold set
  • human-labeled cases
  • compare vs gold
  • agreement · FPR · FNR
  • meets thresholds
  • & beats baseline?
  • keep baseline
  • iterate candidate
  • promote candidate
  • candidate runs in shadow
  • current judge (baseline)
  • reset baseline to new judge
  • judge_calibration
  • no
  • yes
Source and generation provenance

Status: current

Generated at: 2026-08-12T23:39:42.906Z

Source hash: 4d5e0e78924122683a60c75dd665e8181caf7f9e821cebc7ec0dd9ef0313eb56

Metadata payload hash: 0ea1b35e4a4aabc90cbaddbef67f48ba9e4d2682cebf2323fcdf043e05aba9b8

Canonical appearance

src/app/(docs)/docs/concepts/judge-governance/page.tsx:25 route /docs/concepts/judge-governance

All appearances

  • canonicalsrc/app/(docs)/docs/concepts/judge-governance/page.tsx:25 route /docs/concepts/judge-governance

No mirrored appearances.

Generation versions

App: eli-ai 0.1.0

Mermaid: 11.16.0 · Mermaid CLI: 11.16.0

Node: v26.3.1 · Yarn: 4.17.1

Renderer config hash: 68c10966fe84406ee626034d58bfabd555df9f65f691204b7c46db24038da101

Renderer theme hash: c80287a78d80ad63d27bd5ca348b2ef9a7e2f44da289e436be6484ea28a1b033

Adapter versions: diagramGenerator=2, drawioFlowchart=1, drawioGantt=1, drawioSequence=1, drawioState=1

Full sidecar JSON: judge-model-cutover-4d5e0e78.json

This makes a judge change a measured migration, not a leap of faith. If the candidate regresses on FPR, it stays in shadow and the baseline keeps serving — the live quality signal never degrades because someone tried a new prompt.

Baseline resets

When a candidate is promoted, the baseline resets to the new judge: subsequent calibration and drift comparisons measure against the new incumbent, so improvement is always relative to what is actually running. A baseline reset is a deliberate, recorded event — you can see when the judge changed and how the metrics moved across the cutover, which keeps drift-scan history honest across judge generations.

a calibration snapshot (illustrative)json
{
  "judge": "candidate:groundedness-v3",
  "goldSetSize": 240,
  "agreement": 0.94,
  "fpr": 0.03,
  "fnr": 0.11,
  "baseline": "groundedness-v2",
  "mode": "shadow",
  "decision": "promote"
}

Governance closes the loop

The drift scans and eval canaries in Scheduling, drift & alerts depend on the judge. Calibrating the judge against a gold set is what keeps those signals meaningful — governance is the quality control on your quality control.

Related