A tester filed a ticket last month titled "discount stacks in a way nobody expected". It sat in the bug queue for two weeks before anyone worked out it was not a bug at all — it was a genuine product question that had never been decided.
Two different questions
A bug is a gap between the specification and the software: the code does not do what was agreed. A surprise is a gap between the specification and reality: the software does exactly what was agreed, and it turns out nobody thought through what that meant.
Filing both as "bug" sends the surprise to an engineer, who fixes the code to match a decision that was never actually made, and often guesses wrong.
How we sort them now
- Is there a written rule this contradicts? If yes, it is a bug — reproduce it, fix it, done.
- Is there no written rule at all? It is a surprise. It goes to whoever owns the product decision, with the scenario and its consequences, not a suggested fix.
- Is the written rule itself wrong? Also a surprise, and usually the most valuable kind, because it means the acceptance criteria need revisiting before more code is built on top of them.
Why this matters more with generated code
A model implementing a spec will follow it precisely, including the gaps. Where a human engineer might have paused and asked "wait, should two discounts really stack?", a generated implementation just does the literal thing and moves on. That means more surprises are reaching testing intact rather than getting caught earlier as an offhand question in a stand-up.
A surprise is not a lower-priority bug. It is a different kind of finding, and it needs a different kind of owner.
The stacking discount, resolved
The answer, once someone with authority looked at it, was that discounts should not stack past a cap — obvious in hindsight, undecided in the ticket. The fix took twenty minutes. Working out that it needed a decision took two weeks, entirely because it was sitting in the wrong queue.
What we track separately now
Bug count and surprise count are two different lines on our weekly quality report. A team with zero bugs and a growing pile of surprises is not actually in a healthy state — it means the software is precise and the specification is not.