A tax-calculation system — depreciation, entity elections, the kind of statute-driven math where a rounding choice in one clause changes the answer in another — went through a line-by-line audit against the actual code sections it was supposed to implement. That's the normal version of this work. What made it worth writing up is what happened next.
The second pass had one job: disagree
Instead of treating the first audit's findings as done once logged, a second pass ran with an explicit adversarial mandate — take every finding and try to refute it. Not re-check the arithmetic. Argue against the conclusion: is this actually reachable by a real user, given the actual UI paths into the calculator? Does the cited section really apply given the filing status and year in scope? Is the "bug" real, or is it a correct implementation of a rule that just looks wrong at a glance?
A handful of findings from the first pass didn't survive that scrutiny. They were reclassified — not quietly dropped, but written down as "correct as written, but the code path that would trigger the error isn't reachable from any current UI flow." That distinction matters: a dormant bug in an unreachable path is a very different risk than a live one, and treating them the same overstates how broken the system actually was.
Why bother — the first pass already found the real bugs
Because the risk that matters here isn't "did we miss a bug," it's "did we count something as fixed that was never actually a live problem, and did that false confidence hide where the process itself could drift." A finding that gets reclassified as unreachable today can become reachable the moment a single new feature ships — for example, adding a filing-status option that wasn't previously supported can turn three dormant, technically-correct-but-dangerous code paths live on the same commit. Writing that dependency down explicitly is the actual deliverable, not the defect count.
The tradeoff
A second audit pass costs real time and, by design, finds fewer *new* defects than the first — its job is to spend effort trying to talk itself out of results it already has. That's a hard thing to justify on a defect-count basis alone. It's worth it because the alternative — a single pass, taken at face value — has no mechanism for catching the auditor's own overconfidence, and overconfidence in a tax calculator is exactly the failure mode that costs someone real money.
What would change the answer
If the system were small enough, or static enough, that a single careful review could plausibly catch everything and nothing about it would change month to month, the second pass would be overhead without a return. It earns its cost specifically because the underlying rules and the surrounding product both change — a calculator that stops changing stops needing to re-argue with itself.