Golden datasets and golden conversations

Every discipline that ships things it cannot fully predict converges on the same tool: a fixed reference the new version must still satisfy. Type systems have test suites, chips have tape-out checks, and AI systems have golden sets. Here is the practice in plain terms, including the day ours paid for itself.

What golden means

Golden means blessed: a case whose input and acceptable outcome were judged correct by a human and frozen as reference. The suite of them is run after every change (prompt edits, model swaps, new tools, retrieval changes) and the comparison against the blessed outcomes answers the only question that matters before shipping: did anything we rely on just change? Inside the wider eval stack, the golden set is the regression layer: capability tests ask if the system can do the job, boundary tests ask if it refuses what it must, and the golden set asks whether yesterday's correctness survived today's change.

The conversational variant

Single-turn cases grade neatly: extract these fields, refuse this request, exact or rubric-scored. Conversations are where systems actually live and where scores go blind: a dialogue can pass every checkpoint and still have gone wrong (pushier tone, leaked internals, boundary answered one rephrasing later). A golden conversation replays a full real dialogue and puts the new transcript next to the old one for a human read. It is the practice our June incident hardened into standard: the replacement model passed everything except the read, which caught it helpfully writing internal recommendations into the client-facing chat. Scores said fine. The transcript said no.

Scores said fine. The transcript said no. That is why golden conversations get read, not just run.

Curation over volume

• –Source from production. Real cases that went right, blessed. Real cases that went wrong, added after the fix so the fix stays fixed. Adversarial cases written for the boundaries.
• –Cover the three territories: the common path (most volume), the known exceptions (most risk), and the forbidden territory (most damage): for an intake agent, that last set is every phrasing of the questions it must refuse.
• –Keep it small enough to maintain. A few dozen honest cases beat hundreds of stale ones. When the workflow drifts, the set drifts with it or it protects a system that no longer exists.
• –Version it like code. Blessing a new outcome is a reviewed change, because the set is the standard, and quiet edits to standards are how standards die.

The working practice

1. 01Bless the first set from real traffic. A few dozen production cases across the three territories, outcomes judged by whoever owns the workflow.
2. 02Gate every change on the re-run. Prompt edit, model swap, tool change: the set runs, diffs surface, and conversations get read before anything ships.
3. 03Feed it from incidents. Every production surprise becomes a case. The set grows exactly as fast as reality proves it incomplete.
4. 04Rehearse migrations against it. When providers retire models, the golden re-run is the safety net that makes the swap boring.
5. 05Hand it over with the system. Golden data, thresholds, and baseline results transfer in the handover; without them the buyer owns a system with no memory of what correct looked like.

The last two steps are covered end to end in the model-retirement playbook and the ownership handover; OpenAI's own writing makes the broader case for evals. The golden set is the part a business buyer can actually inspect: ask to see it, ask when it last caught something, and treat the answer as the vendor's real quality certificate.