Product 1 min read
The most valuable finding is the one nobody wrote down
Missing requirements get caught in review. Behaviour that was never specified ships silently. Here is why Afara treats "extra" as the finding that matters most.
Afara Product, Product team
When we started showing comparisons to teams, we expected the “missing” findings to be the interesting ones. The ticket asked for an emailed receipt, the code doesn’t send one: that’s a bug, and it’s easy to explain.
It turned out teams mostly knew about those. Someone usually notices when a requirement isn’t built, because someone is waiting for it.
The findings that stopped people in the room were the extras: behaviour in the code that no ticket describes.
Why extras slip through
An extra is almost always a reasonable decision made by one person at the keyboard. The payment provider times out occasionally, so the engineer retries once. A form validates postcodes because the address API rejects bad ones. A guest checkout quietly creates an account so the confirmation email has somewhere to link.
Each of these is fine in isolation. Each of them is also invisible to product, support, legal and QA, who all work from the ticket. A retried authorisation can double-charge a card. A silently created account has privacy implications. Nobody decided these things; they happened.
What Afara does with them
Every extra finding carries:
- the code node, with its file and line range at the compared commit
- a confidence score (high at 0.8 and above, medium from 0.6)
- an explanation of what the code does that the story doesn’t
Someone then decides. Accept it, and it stays accepted in every later comparison: the behaviour is intended, and now it’s written down. Resolve it, and it reopens if a later run finds it again.
In CI, afara compare --fail-on extra holds a build until undocumented behaviour has been looked at by a person. It’s the check we’d most like every team to turn on.