the short answer
Treat the configured evaluator—not Jev in isolation—as the system under test. Validate that its criterion measures the intended construct, compare outputs with blind adjudicated labels, assess class errors and probability calibration, stress wording and evidence changes, and measure latency, failures, review load and downstream decision value. Predefine release gates by consequence and report uncertainty and slice results.
- System under test
- Model plus state, question and decision rule
- Truth
- Blind labels and relevant outcomes
- Core metrics
- Class errors, calibration, coverage and utility
- Robustness
- Paraphrase, missingness, distraction and adversarial tests
- Release standard
- Predefined, slice-aware and consequence-based
First Prove the Criterion Means What the Product Needs
Agreement is meaningless if the target label is wrong. Connect the natural-language question to an operational construct, available evidence and downstream action. “Helpful” may mix correctness, completeness and tone; separate them unless the product intentionally acts on the composite.
Ask whether reviewers can decide from the same evidence Jev receives. High disagreement or frequent missing-evidence labels signals a measurement-design problem before it signals a model problem.
Define the Unit, Label and Action as One Contract
An evaluator can be statistically accurate and operationally useless if it measures the wrong unit or arrives after the decision it is meant to influence. Write this contract before selecting a primitive. The agent-trajectory guide covers evidence boundaries; evals versus policies covers timing and authority.
| Contract field | Example | Why it matters |
|---|---|---|
| Unit | One completed support session | Prevents turns from being counted as independent sessions |
| Criterion | The requested refund was actually created | Names one observable construct |
| Evidence cutoff | Events available when the session closed | Prevents future information leaking into the judgment |
| Reference label | pass, fail or unscorable | Separates missing evidence from a negative answer |
| Application action | Record finding; do not block retrospectively | Connects error costs to actual use |
Use a Scorecard That Spans Model and System Behavior
| Dimension | Evidence | Example release gate |
|---|---|---|
| Discrimination | Confusion matrix, precision/recall, ordinal error | Critical false-negative upper bound below target |
| Calibration | Reliability bins, Brier or log loss | No material overconfidence in allow band |
| Coverage | Share automated, reviewed and unscorable | Review queue remains within capacity |
| Robustness | Paired perturbation and adversarial results | No large change under irrelevant formatting |
| Operations | Latency, provider errors, retries and cost | SLO and budget satisfied |
| Utility | Prevented failures, reviewer time and action loss | Candidate beats current workflow |
Start Error Analysis from the Confusion Matrix
Name the positive class from the action perspective. If “yes” means policy compliance on one page and policy violation on another, generic precision and recall labels invite mistakes. Publish the class definition and raw counts with every percentage.
Accuracy can be nearly perfect when the important failure is rare. For 10,000 sessions with 50 true violations, an evaluator that says “no violation” every time is 99.5% accurate and has zero violation recall. Release gates should therefore target the costly class and relevant slices.
# Example for a Noul criterion where "yes" means a harmful action occurred
human yes human no
Jev yes TP FP
Jev no FN TN
recall_harm = TP / (TP + FN) # how much harmful behavior was found
precision_harm = TP / (TP + FP) # how many flags were valid
false_allow_rate = FN / (TP + FN) # harmful cases missed by the evaluatorQuantify Uncertainty in the Reference Labels
Use at least two independent reviewers on a meaningful subset and report agreement by class. Adjudication may create a release label, but it should not erase the original disagreement. Where real outcomes exist, report both rubric agreement and outcome prediction.
Confidence intervals matter, especially for rare failures. A perfect result on ten critical cases is weak evidence. Bootstrap at the correct grouping unit so repeated turns from one session are not treated as independent samples.
Separate Reviewer Agreement from Adjudicated Truth
Report confusion between reviewers by class, not only one kappa-like scalar. A rare but important label can have poor agreement while the overall number looks acceptable. Inspect every disagreement that changes a consequential action and revise the rubric before measuring Jev.
| Artifact | Purpose | Do not infer |
|---|---|---|
| Independent labels | Reveal ambiguity and reviewer variation | That majority opinion equals downstream success |
| Agreement statistic | Summarize consistency beyond or alongside raw agreement | That every class has adequate agreement |
| Adjudicated label | Create one release reference with a recorded reason | That original disagreement should be deleted |
| Observed outcome | Test whether the construct predicts real consequences | That the evaluator caused the outcome |
Evaluate the Distribution Before Choosing Thresholds
For Noul and Choice, compute proper probability scores and reliability diagrams in addition to top-answer accuracy. For Score, inspect the full ordinal distribution: two cases can share a weighted mean while expressing different uncertainty.
Choose allow, review and block thresholds on calibration data using explicit error costs and review capacity. Report risk versus automated coverage, then evaluate once on untouched test data. See Jev thresholds and calibration.
Compare Candidates Across the Whole Coverage Curve
The table describes the expected trade, not measured results. Build the real curve by replaying held-out distributions through candidate thresholds. Compare Jev, another judge and the current workflow at equal coverage or equal error; comparing each at a different operating point can manufacture a winner.
Include unscorable and provider-failure cases in the denominator. A system that drops difficult inputs can appear accurate because its coverage silently shrinks. The abstention guide explains the application states behind this curve.
| Operating point | Automated coverage | Error among automated cases | Review load |
|---|---|---|---|
| Conservative | Low | Expected to be lowest | Highest |
| Balanced | Medium | Chosen from stated error costs and capacity | Within staffed budget |
| Aggressive | High | Usually higher | Lowest |
Stress Invariances and Documented Weaknesses
Do not assume the model should be invariant to changes that alter evidence. Pair each perturbation with a written expectation. TypeSafe’s documented limitations should become targeted fixtures, not a generic disclaimer.
- Paraphrase the question without changing its meaning.
- Reorder irrelevant fields and remove distracting state.
- Test missing, contradictory and adversarial evidence explicitly.
- Include counting, dates, numeric comparison and multi-hop cases where relevant.
- Repeat a sample to measure instability and provider failures.
- Evaluate language and domain slices actually present in production.
Analyze Candidate Changes as Paired Decisions
When comparing evaluator A with B, retain both outputs for every same held-out session. Count A-only errors, B-only errors, shared errors and corrected errors. This paired view is more informative than subtracting two aggregate accuracies because it exposes whether the candidate fixes the failures that matter or merely exchanges them.
Estimate uncertainty by resampling the independent unit—usually session, conversation, customer or incident. SciPy documents bootstrap confidence intervals, but the grouping choice remains yours. Do not resample individual tool events when several belong to the same session. Predeclare the primary metric and smallest meaningful improvement.
Compare Against the Workflow Being Replaced
A useful evaluator need not maximize standalone accuracy if it safely automates obvious cases and routes uncertainty well. Compare it with existing rules, a generative judge or human-only review on total error cost, review minutes, latency and failure recovery.
Keep explanation requirements explicit. Jev returns typed probabilities, not a rationale. If reviewers need supporting evidence, preserve trace references or use a separate explanatory stage rather than presenting a generated explanation as Jev’s reasoning.
Store a Release Scorecard That Can Be Audited Later
This is an illustrative application artifact, not a Failproof wire format. It records enough context to understand why a candidate moved to shadow without presenting a point estimate as certainty. Store slice tables, raw paired outputs and the configuration hash alongside it.
{
"evaluator": "refund-completion@v3",
"model": "jev-1.13.0",
"dataset": "refund-heldout@2026-09",
"unique_sessions": 420,
"primary_gate": {
"metric": "false_allow_rate",
"estimate": 0.012,
"upper_confidence_bound": 0.024,
"maximum": 0.030
},
"coverage": {"automated": 0.71, "review": 0.26, "unscorable": 0.03},
"critical_fixture_failures": 0,
"decision": "shadow"
}Make the Release Decision Reproducible
Use explicit outcomes: reject, revise, shadow, limited release or promote. “Looks good” is not a release state. Shadow means results are recorded but cannot change the user-visible action; limited release names the slices and traffic share where evidence applies.
The release report should state what remains unsupported. A strong result on English refund sessions does not authorize multilingual safety screening. The regression guide turns the approved scorecard into CI gates, and drift monitoring tests whether its assumptions continue to hold.
- Pre-register primary metrics, slices, gates and exclusion rules.
- Pin the complete evaluator and dataset versions.
- Run once on the untouched test set and retain raw outputs.
- Document failures, uncertainty and unsupported deployment contexts.
- Shadow on live traffic and verify review capacity and outcomes.
- Promote with monitoring, rollback and a scheduled revalidation owner.
FAQ
Is agreement with one reviewer enough?
Usually not. Measure reviewer disagreement and use adjudication or outcomes; one reviewer can encode inconsistent personal preferences.
Is accuracy enough for a Jev evaluator?
No. Include class-specific errors, calibration, coverage, slices, robustness, latency, failures, cost and downstream utility.
Should I tune on every failure?
No. Separate development, calibration and final test sets. Repeatedly tuning on test failures invalidates the estimate.
Can Jev evaluate itself?
A Jev result can be another signal, but release evidence needs independent labels or outcomes. Self-agreement is not validation.
Sources
Checked against the sources below on September 22, 2026. Model versions, prices and limits change.
- NIST AI RMF: Measure function
- scikit-learn: Probability calibration
- scikit-learn: Classification metrics
- SciPy: Bootstrap confidence intervals
- TypeSafe AI docs: Primitives
- TypeSafe AI docs: Jev 1.13 jaggedness
- LangChain: Can Jev be a better agent evaluator?
- Zheng et al.: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena