Skip to main content
AI & Agents

Eval Harness

An eval harness is the infrastructure that runs an AI system against a fixed set of inputs with verified expected outcomes and scores the results, turning every prompt change, model swap or tool update into a measurable event. It is the regression suite for behaviour that cannot be checked with an equals sign.

A harness has four parts. The dataset holds cases — inputs paired with expected outcomes or a grading rubric. The runner executes the system against every case, ideally against the production prompt and tool configuration. The scorers grade each run. The report diffs results against the previous baseline, so a change that breaks three cases is visible before it ships rather than after a user finds it.

Scoring splits by answer type. Objective behaviour gets deterministic checks — did it call the right tool, is the output valid against the schema, did it stay within policy. Subjective quality gets a model-graded judge with a written rubric, and that judge must itself be calibrated against human ratings before its scores mean anything; an uncalibrated judge produces confident numbers about nothing. The cases a judge cannot settle go to human review.

The golden set is curated, not collected. The best cases come from production failures and human-in-the-loop corrections — real inputs the system actually got wrong — plus adversarial cases including prompt-injection attempts. Fifty reviewed cases outperform a thousand unreviewed ones. The harness earns its keep in CI, where it gates releases: a change that drops the pass rate or the judge score does not deploy, which is what makes an AI system maintainable rather than frozen.

Public benchmarks and private evals answer different questions. Suites like lm-evaluation-harness or HELM rank foundation models on generic tasks and are useful for shortlisting candidates; they say little about your system, because your prompts, tools and data distribution are the system. The golden set that matters is built from your own tasks, and it has to be protected — cases that leak into training data or get overfit through repeated tuning stop measuring anything.

Everything in the harness is versioned: the dataset, the prompt templates, the judge prompts and the scorers themselves. A score only means something against a frozen configuration, and an improvement that cannot be tied to a specific change is superstition. Mature teams store results per commit, so the answer to "when did this regress" is a lookup rather than an archaeology project, and model upgrades become a controlled experiment instead of a leap.

Codazz builds this in production — Evaluation & Observability.

FAQ

Eval Harness
FAQ.

Common questions about eval harness.

Ask Us Anything

Fewer than you think, but better than you have. Fifty to a hundred carefully reviewed cases covering the core tasks, known edge cases and past failures will catch most regressions. Grow the set from production incidents — every real failure becomes a permanent case — rather than by generating bulk synthetic examples that all test the same easy path.

Observability watches the live system and tells you what happened; the harness gates change and tells you what will happen. They feed each other: observability surfaces production failures that become eval cases, and eval scores explain whether a behaviour shift seen in production came from a deliberate change or a silent model update.

Avoid it where possible. A model grading its own outputs inherits its own blind spots and biases scores toward fluent answers. Use a different, typically stronger model as the judge, give it a written rubric rather than a vibe check, and spot-check its grades against human review regularly. When judge and system share a model family, that calibration against human ratings becomes even more important.

Related terms

Agent Evaluation

Agent evaluation is the practice of scoring an AI agent against a fixed set of real tasks with verified expected outcomes, so that every prompt change, model swap or tool update can be measured rather than guessed at.

LLM Observability

LLM observability is the practice of tracing and measuring every model call in production — prompts, completions, tool invocations, latency, token usage and cost — so that non-deterministic systems can be debugged and regressions caught.

Human-in-the-Loop (HITL)

Human-in-the-loop is a design pattern where an AI system pauses and requires a person to approve, modify or reject an action before it proceeds.

Browse the full glossary →