Golden Datasets

The Story

In early 2024, Klarna — the European fintech company — replaced approximately 700 customer service agents with an AI assistant. The company claimed the system could handle two-thirds of all customer interactions and projected $40 million in savings. By conventional usage metrics, the rollout looked strong.

Within months, customer satisfaction had dropped significantly. The AI handled routine queries well. Where it failed was on complex cases: disputed charges requiring policy judgment, cross-border issues with regulatory nuance, emotional situations where a customer needed to feel heard before they needed an answer.

By early 2025, the CEO admitted publicly: "We went too far." Klarna began rehiring human agents and piloting a hybrid model. The core issue wasn't the model. It was the test coverage. The pattern suggests the golden dataset didn't include the hard cases.

When your golden dataset is 90% happy-path, your eval score will look great. And it will lie to you.

The Core Idea

In Failure Anatomy, you learned how to read raw traces and build a taxonomy of how your product fails. That taxonomy tells you WHERE the problems are. The golden dataset is where that knowledge becomes a test you can run repeatedly, automatically, every time something changes.

A golden dataset is a curated collection of inputs paired with verified correct outputs — your answer key. Each entry says: "For this specific input, here's what a correct response looks like." When you change a prompt, swap a model, update your retrieval pipeline, or modify a guardrail, you run the new version against every entry and compare.

The word "golden" matters. These aren't random production logs. They're curated, verified, and versioned — tracked like source code.

The ratio that separates honest evals from flattering ones is 60/25/15. 60% representative cases — the common scenarios your product handles every day. 25% edge cases — less common but predictable. 15% adversarial — inputs specifically designed to break your system.

For agents, the golden dataset row changes fundamentally. For single-turn systems, a golden dataset entry is straightforward: input to expected output. For multi-step agents, an entry needs to be richer: task + environment state + allowed tools + expected trajectory + expected final state. You're testing the path, not just the destination.

Building from real data, then expanding with synthetic generation. The best golden datasets start with real production examples. Pull 50-100 actual cases from your logs. Then expand systematically using dimensional axes — persona, complexity, domain, scenario type. You can use LLMs to generate the inputs, but domain experts must verify or write the expected outputs.

Where This Hits in Production

In enterprise B2B, one golden dataset is the wrong abstraction. The right model is a dataset family with metadata overlays. The same scenario might have different correct answers for different tenants — because they have different policies, contracts, and compliance requirements.

Privacy constraints change the golden dataset build pipeline. In healthcare and financial services, building golden datasets means mining production logs that contain PII. The operational pipeline: production trace, redaction/tokenization, triage, domain expert review, golden candidate, versioned dataset commit.

Version control is the maturity signal. The difference between a team that has golden datasets and a team that has golden dataset infrastructure: version pinning, per-slice release gates, and an incident-to-golden SLA.

Connecting the Dots

The golden dataset is where two separate ideas from earlier topics converge. From Non-Determinism: because the same input produces different outputs across runs, you need to run each golden case multiple times to measure stability. From Failure Anatomy: the failure categories you discovered become the scenarios your golden dataset must cover.

One insight that changed how I think about golden datasets: have failing evals. If every eval in your suite succeeds, you have blind spots. Deliberately include golden cases you expect to fail. When a new model drops, rerun them first.

Don't just use golden datasets to test what you've built. Use them to define what you're waiting to build.

Remember This

1. Your golden dataset is your answer key. The quality of every eval, metric, and dashboard you build can never exceed the quality of this dataset. Design the ratio deliberately: 60% representative, 25% edge cases, 15% adversarial.

2. For agents, the golden dataset row isn't input to output. It's task + environment state + allowed tools + expected trajectory + expected final state. You're testing the path, not just the destination.

3. A frozen golden dataset is a private benchmark. Rotate fresh cases from production every sprint. The dataset should be harder than production, not easier.

In Practice: Happy Path vs. Balanced

Here's what the difference looks like when you compare a happy-path-only test suite against a properly balanced golden dataset for the same product.