Part 10 — Integrated Case Studies

Designing the next hidden test

What it proves and what's next·Evaluation·7 min read

An evaluation isn't finished when it produces a number — it's a living program. This chapter is about the case study's next move: designing a fresh hidden test that resists contamination, targets the boundaries the last one exposed, and keeps the evaluation honest as the system improves.

The case study produced a bounded result — and the right response to a finished evaluation is not to stop but to plan the next one. An evaluation is a living program, and the held-out set that gave the honest 95.5% has now been used: looked at, learned from, iterated near. So the project's next move is to design a fresh hidden test — one that resists contamination, targets the boundaries the last round exposed, and keeps the evaluation honest as the systems get better. This chapter is that forward step.

What you will understand by the end

  • Why the current hidden set has a limited shelf life.
  • How to design a fresh hidden test that resists contamination.
  • Why the next test should target the boundaries the last one revealed.
  • How this closes the case study's loop into continuous evaluation.

Why the current hidden set ages

The held-out 60 gave an honest number because the systems were never tuned on them. But every use spends a little of that honesty: as the team reads results, iterates, and makes decisions informed by that set, it slowly drifts from a pristine hidden set toward a development set. It's not ruined after one use, but its value as an unbiased estimate erodes with exposure — which is exactly why maintaining an evaluation program includes refreshing hidden sets on a schedule. The next honest number needs data the current systems haven't been shaped against.

Key idea

A hidden set's value decays with use. The 95.5% was honest because the held-out 60 were untouched during iteration — but now that they've informed decisions, the next honest estimate needs a fresh hidden test the systems have never seen. Designing the next hidden test isn't optional polish; it's how the evaluation stays trustworthy as the project continues.

Designing it to resist contamination

The next hidden test inherits the contamination defences that made the first one trustworthy, and adds a rule of use:

  • Author it privately, for this schema and domain, so the base models can't have seen it — the same guard that protected the original.
  • Keep it sealed until it's time to report, and budget its exposure — decide up front how many times it will be run, and refresh again once that budget is spent.
  • De-duplicate it against the development and previous held-out sets, so nothing the systems were tuned on leaks back in.

Target the boundaries the last round exposed

A fresh test is also a chance to make the evaluation harder where it matters. The last round's diagnosis named the systems' fragility precisely — the ranking-vs-breakdown boundary — so the next hidden test should over-sample that boundary and the near-misses around it, following the adversarial principle. As the systems improve on the failures you already found, the frontier moves; the next test should probe the new frontier, not just re-run the old one. This is the incidents-to-tests loop in slow motion: what you learned becomes the next set's design.

Watch out

Two failure modes to avoid in the next test. Building it from the same easy distribution just re-confirms what you already know while the systems' real weaknesses go unmeasured. And re-using the old hidden set "one more time" quietly tunes on it. The next test must be fresh (uncontaminated) and harder at the right places (targeting the exposed boundaries) to actually advance what you know.

Closing the case study's loop

Designing the next hidden test is where the case study stops being a one-shot experiment and becomes a continuous evaluation program. The result informed a provisional decision; the diagnosis named the weaknesses; the next test targets those weaknesses on fresh data; the cycle repeats, each round harder and each honest number earned on data the systems haven't seen. This is the same maintenance and incidents-to-tests discipline from Part 9, applied to the project's own future.

Observed evidence

The project treats its hidden test as something to be re-designed, not built once — planning the next hidden set as failure modes surface, precisely so the number keeps meaning something as the systems evolve. That "design the next hidden test" posture is what turns a single 95.5% into an ongoing, trustworthy evaluation. The failures that shape the next test →

Mental model

A hidden set decays with use, so the honest 95.5% can't be re-earned on the same data. The next move is a fresh hidden test — privately authored, sealed, exposure-budgeted, de-duplicated — that targets the boundaries the last round exposed (ranking-vs-breakdown and the new frontier). That turns the one-shot experiment into a continuous, self-improving evaluation program.

Common mistakes

  • Re-using the old hidden set. Its honesty is spent; "one more run" quietly tunes on it.
  • Rebuilding from the same easy distribution. It re-confirms the known and leaves real weaknesses unmeasured.
  • Pulling from public benchmarks. Reintroduces contamination the private authoring was meant to prevent.
  • Not targeting the exposed boundaries. The frontier has moved; the next test should probe where the systems are now fragile.

Practical guidance

  • Refresh the hidden set on a schedule and once its exposure budget is spent — never re-report on a used one.
  • Author the next test privately and sealed, de-duplicated against dev and prior held-out data, to resist contamination.
  • Over-sample the boundaries the last diagnosis exposed and the new frontier, following the adversarial principle.
  • Treat "design the next hidden test" as a standing task — it's what keeps the evaluation honest as the systems improve.

Summary

  • A hidden set's value decays with use, so the next honest number needs a fresh test the systems haven't seen.
  • Design it to resist contamination — privately authored, sealed, exposure-budgeted, de-duplicated.
  • Target the boundaries the last round exposed (and the new frontier), following the adversarial principle.
  • This closes the case study's loop into a continuous, self-improving evaluation program.

Knowledge check

The held-out 60 gave an honest 95.5%. Why can't you just re-run them to measure the next version of the system?

Because that hidden set's value has decayed with use. It gave an honest number the first time precisely because the systems were never tuned on it — but the team has now read those results, iterated, and made decisions informed by them, so re-running the same 60 to evaluate the next version would be tuning on the test set: the new version was shaped, directly or indirectly, by what those tasks revealed. The re-run number would be optimistically biased by an unmeasurable amount. The next honest estimate needs a fresh hidden test the current systems have never influenced — privately authored, sealed, and ideally harder at the boundaries the last round exposed.

Beyond being fresh, why should the next hidden test over-sample the ranking-vs-breakdown boundary?

Because the last round's diagnosis named that boundary as the systems' key weakness, and as they improve on the failures already found, the evaluation must probe the new frontier rather than re-confirm what's already handled. A fresh test drawn from the same easy distribution would mostly re-measure solved cases and let the real fragility go unmeasured. Over-sampling the ranking-vs-breakdown boundary (and its near-misses), following the adversarial principle, concentrates the test where the systems are most likely to still fail — so the next number actually advances what you know about their weaknesses instead of just re-stating their strengths. It's the incidents-to-tests loop: what you learned becomes the next set's design.

Related chapters