eval-before-ship

name	eval-before-ship
description	Use before merging, deploying, or demo'ing any LLM feature. Requires documented eval results — pass rate, failure analysis, baseline comparison. Blocks "it looked good when I tested it" completions.

Eval Before Ship

The Law

AN LLM FEATURE IS NOT READY UNTIL NUMBERS EXIST.
"It looked good when I tested it" is not an eval.
"I ran a few examples and it worked" is not an eval.
A named suite, a defined metric, a pass rate, a failure analysis,
and a baseline comparison IS an eval. All five. Not four.

When to Use

Trigger before any of these:

• Merging a PR that adds or modifies a prompt
• Deploying an LLM feature to any environment users can reach
• Switching models or providers on an existing feature
• Changing retrieval logic, rerankers, or chunk strategy in a RAG pipeline
• Updating few-shot examples or system prompt structure

When NOT to Use

• Exploratory prototypes that will not reach users (note it: "eval required before production")
• Config-only changes that cannot affect model output (timeouts, logging, env vars)

What Counts as an Eval

An eval must have all five components:

Component	What It Means	What Does NOT Count
Named test suite	File with labelled examples in evals/	"I tested it manually"
Defined metric	Accuracy %, faithfulness score, task pass rate	"It seemed accurate"
Pass threshold	Explicit minimum (e.g., ≥ 85%)	No threshold = no standard
Failure analysis	≥ 5 failures examined and categorised	"There were a few errors"
Baseline comparison	This version vs. previous version or control	First release exempt; all subsequent require it

The Process

Step 1 — Define the Eval Before Writing the Prompt

Answer these before touching the prompt:

• What does a correct output look like for this task?
• What metric will you use to measure it?
• What is the minimum acceptable score for production?

If you cannot answer these before building, the task is not well enough specified to build.

Step 2 — Build a Representative Test Set

evals/
  <feature-name>/
    test-set.jsonl     ← labelled examples, one JSON object per line
    harness.py         ← eval runner
    results-<date>.md  ← documented results

test-set.jsonl format:

{"id": "001", "input": "...", "expected": "...", "tags": ["edge-case"]}

Label ground truth before running any model. Seeing outputs first contaminates labels.

Minimum 50 examples; 200+ for features used at volume. Include: edge cases, short inputs, long inputs, ambiguous inputs, adversarial rephrasing.

Step 3 — Run and Record

python evals/<feature-name>/harness.py --model <model-id> --seed 42

Record: pass rate (X/N = Y%), latency p50/p95, failure category breakdown.

Step 4 — Analyse Failures

Examine every failing case. Assign each to one category:

• Format violation — wrong output structure
• Factual error — wrong answer when correct answer was in context
• Hallucination — claim not grounded in any provided context
• Refusal — model declined a legitimate request
• Off-topic — response doesn't address the input

The most common failure category is your next fix.

Step 5 — Document

Suite: evals/email-classifier/test-set.jsonl (200 examples)
Model: claude-sonnet-4-6, temperature: 0.0, seed: 42

Pass rate: 178/200 = 89% (threshold: ≥ 85% ✓)

Failure breakdown:
  - Format violation: 12 (long emails > 2000 tokens)
  - Hallucination: 10 (invented labels not in schema)

Baseline: v1 (82%) → v2 (89%), delta: +7pp ✓
Results: evals/email-classifier/results-2026-06-07.md

Rationalization Red Flags

These thoughts mean you have NOT completed an eval — stop and build one:

• "I ran it manually and it looked good" — you tested a sample you chose; an eval tests a sample that represents the distribution
• "We'll add evals after we ship" — the regression will be a 2-week cycle: 3 days to notice, 2 days to diagnose with no baseline, 1 week to ship the fix; the eval would have taken a day
• "The model always does this correctly" — based on how many labelled examples?
• "It's only an internal tool" — internal tools fail the same ways, just with fewer headlines
• "This is a small prompt change" — adding a single instruction shifted one team's pass rate from 89% to 72%; "small" has no meaning in output distribution terms
• "We don't have time to build a test set" — you have time to diagnose production failures?

Completion Statement Format

When eval-before-ship is satisfied, state it like this:

Eval complete.
Suite: evals/<feature>/test-set.jsonl — N examples
Model: <model-id>, temperature: X, seed: Y
Pass rate: A/N = B% (threshold: ≥ C% ✓)
Top failure mode: <category> (N cases — <root cause>)
Failure analysis: evals/<feature>/failure-analysis-<date>.md ✓
Baseline: <previous> = X% → this version = Y%, delta: +Zpp ✓
  [First release: baseline field may be marked "N/A — initial version"]
Results stored: evals/<feature>/results-<date>.md ✓

The pass rate, failure analysis, and baseline comparison are not optional. On the first release, baseline may be marked "N/A — initial version"; for all subsequent releases it is required.

Why This Matters

LLM outputs are stochastic. A prompt that works on the examples you tried does not predict performance on the next 1000 inputs. Eval suites catch regressions before users do — and they make it possible to improve without guessing.