An eval that has never failed tells you very little. If your suite has been green for months, there are two explanations: the system is excellent, or the checks cannot detect the problems you care about. From the outside, they look identical.
The cheap way to tell them apart is to sabotage on purpose.
Plant a known-bad case
Take your current prompt or pipeline and deliberately break it in a way you would consider a real regression: remove the key instruction, swap in a much weaker model, or feed the grader an answer you know is wrong. Run the eval. If the score barely moves, the eval is not measuring what you thought. This is the same idea as mutation testing for code, and it takes about an hour the first time.
Three sabotages worth trying:
- Delete the most important rule in the system prompt. Does anything fail?
- Return an empty or irrelevant answer for a handful of cases. Does the grader notice?
- Shuffle the expected answers across cases. Pass rates should collapse. If they do not, the grader is rewarding style, not correctness.
Keep the sabotage as a permanent test
Once you have a break that the eval catches, keep it as a canary: a deliberately degraded variant that must score below a threshold in CI. If a later grader or rubric change lets the canary through, you find out immediately instead of months later when production disagrees with your dashboard.
Why this matters
Evals decay quietly. Rubrics get loosened to stop noisy failures, datasets get easier as hard cases are fixed and removed, and graders drift. Each change is reasonable alone. Together they can turn a sharp instrument into a rubber stamp. A canary that must fail is the one signal that does not erode that way.
The practical step this week: pick your most important eval, break the system on purpose, and see whether the score notices. If it does not, you have just found your highest-value bug.