Glossary

Measurement

Golden dataset

Also called: frozen case set, evaluation set

Definition

A golden dataset is a fixed, representative set of real cases with agreed correct outcomes, held constant so that performance can be compared across releases.

It is the single highest-leverage artefact in an AI program and the one most often skipped under launch pressure. Without it there is no way to tell an improvement from a regression, no way to detect drift, and no way to compare two models honestly against the same standard. Building one costs weeks of expert time and pays for itself the first time it prevents a bad release from reaching production.

Representative includes the ugly cases

A set drawn only from clean files flatters the system, because clean files are the easy cases that almost any reasonable approach handles correctly. Deliberately include the ambiguous, the incomplete, and the adversarial, in roughly the proportion they occur in real operations, because those are the cases where a genuine performance difference between two models or two versions actually shows up, and where the eventual production failures are disproportionately likely to originate.

Freeze it, then guard it

If the set changes every quarter, the trend line means nothing, because you can no longer tell whether a score change reflects the system getting better or worse, or simply reflects a different, easier or harder set of test cases being used this time. Version it, keep it out of training and prompts, and change it only deliberately, with a clear record of when and why the set changed, so historical comparisons remain meaningful.

One dataset is rarely enough for a mature program

As a program matures, a single golden dataset built at launch tends to miss new case types that emerge as volumes grow or as the business changes, and teams that rely on only the original set risk a false sense of security about coverage. Periodically sampling new production cases into a supplementary, separately versioned set — without contaminating the original benchmark — keeps the evaluation program honest about what it is and is not actually testing for.

In practice

  • Have experienced practitioners label the outcomes, not the build team alone
  • Keep the set out of prompts and fine-tuning to avoid contamination
  • Re-score it on every release and on a fixed monthly cadence
  • Periodically sample new case types into a separate, versioned supplementary set

Related terms