Development set
The cases you read, debug against and tune prompts on.
- Read every failure
- Edit prompts against it
- Grows with each bug found
Guide · AI agent evaluation
What is a golden dataset, and how do you build one?
A golden dataset is the answer key you test an AI system against: real inputs, the answers a careful expert would give, and a rule for deciding what counts as right.
Every score you report about an AI agent — accuracy, consistency, whether a change made things worse — is only as good as the cases behind it. This guide takes a golden dataset apart record by record, shows how it differs from ground truth and public benchmarks, works out how many cases you need, and lays out how to build one and keep it honest.
Updated · 5 sources
One golden recordan input, its verified answer, and how to grade it
The inputa real document, question or conversation
Expected answerwhat a careful expert would return
Match ruleexact, fuzzy, numeric with tolerance, date, list or rubric
Critical flagfields that must never be wrong
Tagsformat, edge case, source system, difficulty
Provenancewho verified it, and when
Versionthe dataset release it belongs to
Why it is herethe failure or risk it was added to catch
What is a golden dataset?
A golden dataset is a curated, versioned set of real inputs paired with verified expected outputs, used as the answer key when evaluating an AI model, agent or workflow. Each case says what the system receives, what a careful expert would answer, and how to judge a match. Because it is frozen per version, two runs scored on it can be compared fairly — which is what lets you say a change made things better or worse.
Inside the dataset
What a golden dataset record holds: input, answer and a rule for each field.
The match rule is the part most teams leave out. “Acme Corp.” and “ACME Corporation” are the same supplier; 18,240.50 and 18,240.5 are the same total. Without a rule per field, string equality marks right answers wrong and the score means nothing.
id: invoice-0142
input: invoice-0142.pdf
verified_by: two reviewers, agreed
tags: [scanned, multi-page, EUR]
expected:
supplier "Northwind Traders" fuzzy ≥ 0.85
invoice_date 2026-03-14 date
total 18240.50 numeric ±0.5% critical
currency "EUR" exact critical
po_number "PO-77310" exact
line_items 12 rows listMatch rules, and when to use each
- ExactCodes, identifiers, currencies, yes-or-no labels.
- FuzzyNames and addresses that can be written several ways.
- Numeric with toleranceAmounts and measures, within a stated margin.
- DateAny format that resolves to the same day.
- ListLine items or entities, matched item by item.
- RubricFree text — a summary, a reply — graded by a person or an LLM judge against stated criteria.
Record why each case exists. A case added to catch a past failure is worth more than a random one. Tag it with the failure, so a later reader knows what breaks if it is deleted.
Terms that get mixed up
How a golden dataset differs from ground truth, benchmarks and training data.
Four terms overlap in everyday use. The differences matter when you decide who owns the set, how often it changes and whether a model may ever see it.
| Ground truth | Public benchmark | Training data | Golden dataset | |
|---|---|---|---|---|
| What it is | The true answer for one case | A shared test set for comparing models | Examples a model learns from | Your curated, frozen set of cases with verified answers |
| Whose task | Any | A general skill | The model’s | Your system, on your work |
| Changes | Never, for that case | Rarely, by its maintainers | Often | In numbered versions you control |
| Model may see it | — | May already sit in training data | Yes | Never — that would void the test |
| Answers the question | What is right here? | Which model is stronger in general? | What should the model learn? | Does our system do our job, and did a change help? |
Held-out set
Cases kept back, run only to confirm a change before release.
- Never tuned against
- Catches overfitting to the dev set
- Refreshed from new production cases
Step by step
How to build a golden dataset in five steps.
Start small and real. Anthropic’s guidance for agent evaluations is to begin with a few dozen tasks drawn from real failures rather than wait for hundreds — then grow the set as the system meets new work.
- Collect real inputs
From production logs, the backlog of past cases and the failures people reported. Synthetic cases only fill named gaps.
- Cover the spread
Common formats in proportion, plus edge cases, cases that should be refused and adversarial ones.
- Write the answers
Two domain experts answer each case on their own, with the source in front of them.
- Reconcile
Where the two disagree, settle it or drop the case: an ambiguous case cannot be graded fairly.
- Freeze and version
Publish it as version 1, with a datasheet of what it covers and how it was made.
Document it like any other test asset. NIST’s AI Risk Management Framework (MEASURE 2.1) asks that test sets, metrics and the tools used in testing be documented. A short datasheet in the style Gebru et al. proposed — why the set exists, what it contains, how cases were collected and labelled, who maintains it — does the job.
Size and coverage
How big a golden dataset needs to be, and what it has to cover.
Size decides how small a change you can see. By the standard formula for a proportion, a score from 50 cases can swing by ten points on noise alone, and telling two separate runs apart by two points takes thousands of cases each. Coverage decides whether the score means anything for real work.
Tens of casesThousands of cases
1234
- 50 casesAn 80% score is honest to about ±11 points. Enough to find what is broken.
- 200 casesAbout ±5.5 points. Enough to compare two very different designs.
- 1,000 casesAbout ±2.5 points. Enough to gate a release on a floor.
- 5,000 casesAbout ±1.1 points. Enough to see a small regression after a model change.
What the cases must cover
- The common work, in proportionMirror the real mix of formats, sources and requests, or the average will mislead.
- Edge casesMissing or irrelevant input, very long input, unusual layouts, other languages.
- Cases that should not triggerTest where a behaviour should happen and where it should not, so the system is not tuned one way.
- Hard casesRare layouts, poor scans and judgement calls — few, tagged, and only where two experts still agree on the answer.
- Adversarial inputInjected instructions in documents, hostile users, malformed files.
- Recent production failuresEach one found live becomes a case, so it cannot come back unnoticed.
The margins above are our own arithmetic, not a published table: the normal-approximation 95% interval for a proportion, 1.96 × √(p(1 − p) / n), with p = 0.8. For 50 cases that is 1.96 × √(0.16 / 50) ≈ 0.11, or ±11 points. Comparing two runs case by case on the same cases is tighter than comparing two separate scores, because both runs face the same questions and only the cases that flip carry information.
Maintenance
Keeping a golden dataset honest: versions, failures and saturation.
A golden dataset is never finished. The work changes, models change, and a set that every version passes stops telling you anything.
The upkeep cycle
- RunScore every change, and on a schedule when nothing changed.
- Read failuresRead the transcripts: is the system wrong, or the answer key?
- Fix the keyCorrect wrong answers and drop cases two experts cannot agree on.
- Add new casesEach production failure and each new format becomes a case.
release the next version, and compare new runs only with runs on the same version
Capability vs regression
A capability set starts with a low pass rate to climb; a regression set should sit near 100%. Cases graduate from the first to the second.
Saturation
When every version passes, the set still guards against regressions but no longer shows improvement. Add harder cases.
Tuning to the test
Prompts edited against the same cases for months fit those cases. Keep a held-out set and refresh it.
On Botminds
How Botminds builds and uses a golden dataset for every agent.
On Botminds a golden dataset is built like an asset: versioned, reviewed and shaped to the job — and any agent, workflow or mesh can be scored against one.
Four kinds of case
Documents with expected fields, packages with cross-document rules, questions with answers, and conversation scenarios.
A rule per field
Exact, fuzzy, numeric with a tolerance, date or list — a right answer written differently still scores right.
Critical fields
Fields that must never be wrong weigh double and get their own accuracy line.
Versioned and reviewed
Every edit is a new version; each case is verified before it becomes the answer key.
- Build
Golden datasets grow to thousands of cases.
- Run
Cases run side by side, each repeated to measure consistency.
- Compare
Each run is compared case by case with a pinned baseline.
- Gate
Set an agent’s evaluations to run on every publish; a worse change is flagged with the reason.
- Grow
Add each failure found live to the dataset, so the answer key keeps pace with the work.
Read the full design in AI agent evaluation, and set one up in the Academy lesson crew and evaluations.
Questions people ask
What is a golden dataset: common questions.
The technology behind itEvaluation & observabilityEvery change measured, every run watched→What is a golden dataset in AI?
A golden dataset is a curated, versioned set of real inputs with verified expected outputs, used as the answer key to evaluate an AI model, agent or workflow. It is frozen per version so that two runs can be compared on exactly the same cases.
What is a golden dataset for LLM evaluation?
For an LLM application, each case pairs a prompt or document with the answer a careful expert would give and a rule for judging a match — exact, fuzzy, numeric, or a rubric graded by a person or an LLM judge for free text.
What is the difference between a golden dataset and ground truth?
Ground truth is the true answer for one case. A golden dataset is a curated collection of such cases, chosen to test what matters, versioned, and documented — the full answer key rather than a single answer.
How big should a golden dataset be?
Start with 20 to 50 real cases to find what is broken. To detect a few points of change you need hundreds to thousands: at 80% accuracy the 95% margin of error is roughly ±11 points with 50 cases and ±2.5 with 1,000 (the standard binomial formula).
How do you create a golden dataset?
Collect real inputs from production and past failures, cover the common work in proportion plus edge and adversarial cases, have two experts answer each case independently, settle or drop disagreements, then freeze and version it with a short datasheet.
What is a golden dataset in RAG?
For retrieval-augmented generation, each case holds a question, the passages that should be retrieved and the expected answer, so retrieval and generation can be scored separately.
Can a golden dataset be synthetic?
Partly. Generated cases are useful to fill named gaps — a rare format, a hostile input — but the core should be real work, and every case, generated or not, needs a verified answer.
How often should a golden dataset be updated?
Whenever production shows a new failure or format, and in numbered versions. Compare runs only within one version; when the set saturates, add harder cases.
Sources
- Anthropic: Demystifying evals for AI agents (January 2026)anthropic.com
- Anthropic docs: Create strong empirical evaluationsplatform.claude.com
- OpenAI: Evaluation best practicesdevelopers.openai.com
- NIST AI 100-1: AI Risk Management Framework 1.0nvlpubs.nist.gov
- Gebru et al.: Datasheets for Datasets (2018)arxiv.org
Read next
LLM evaluation metricsBLEU to pass^k: what each metric measures and which one fits your task→LLM as a judgeHow model graders work, the biases research found, and how to calibrate one→AI agent vs LLM observabilityWhat a model-call trace shows, what an agent trace adds, and what to watch→All guidesEvery explainer, by topic→
See it on
your own work.
Bring one process and its documents. We’ll show you the agents, the controls and the record, running on your data.