Why Passing Your Eval Suite Isn't the Same as Being Ready to Ship
A green eval suite is a strong signal about one thing: the model does what you tested it on. It's a much weaker signal about whether the *feature* is ready for real traffic, and teams that treat the two as equivalent tend to find out the difference in production instead of in review.
An eval suite runs the model in a vacuum — clean inputs, no load, no partial failures upstream, no user who phrases the question strangely because they're frustrated about something else. It can't tell you whether anyone will notice if the feature quietly breaks at 2 a.m., whether there's a way to turn it off without a deploy, or whether the first hundred real users will hit an input pattern your test set didn't cover.
So before shipping, it's worth checking for a short list of things a passing eval says nothing about:
- An owner. Someone whose job it is to notice when this breaks, not just whoever happened to write it.
- A production signal. A metric or alert that would catch degraded quality without a human reading transcripts.
- A rollback path. A way to revert behavior that doesn't require a full deploy cycle.
- A plan for week one. What you'll actually look at once real traffic starts arriving — not just "the eval passed, so we're done."
None of this replaces good evals — it sits alongside them. The eval suite answers "does the model do the right thing on the inputs we thought to test." Everything above answers "what happens when it doesn't, and who finds out first." Ship when you have honest answers to both, not just the first one.