smallbox

Method

How I know important behavior is correct.

Most software is verified by “the tests pass and nobody complained.” For behavior that matters — money, quantities, published figures — that is not enough, because code can agree with itself while being wrong. In my own production system, important numbers are held to a stronger standard, and I bring the same standard to client work.

Independent recomputation.

Every important derived figure is recomputed a second way, and the two implementations are kept independent exactly where sharing code could reproduce the same defect: different implementation, same declared inputs. Agreement between two independent computations is evidence; agreement of code with itself is not. This has caught real defects — a square-root routine that silently failed to converge was exposed by 215 recompute contradictions.

The claim has a limit, and the limit is part of the method: independence reduces correlated implementation errors; it does not eliminate errors in what both computations were told. A verifier of mine once reproduced a calculation exactly while both it and the code read the same mislabelled column — both wrong, in agreement. Which is why the method has a second half, below.

Evidence, not assertions.

A verified claim stores its working: the claim, the inputs, the step-by-step calculation, and the date it held. When a number is questioned months later, the answer is a lookup, not an archaeology dig.

Guards proven by breaking things.

A test that has never failed proves nothing. When I add a guard, I deliberately break the code it protects, watch the guard go red, then restore it. One extra minute per guard, and it is the difference between “we have checks” and “the checks bite.”

A published trust state, including the failures.

My product publishes its per-measure verification state live — including the measures still marked untrusted — beside a dated public record of corrections. I would rather show a reader an honest “not yet verified” than a confident wrong number. Both pages are linked below; they are live, not screenshots.

The second half: hunting the shared assumption.

When every check agrees, the remaining risk is whatever they all assume. A “latest row” query ordered by insertion time instead of business date picked the wrong row for 81% of records — while every value-level check passed, because each value was individually plausible. A whole family of checks once shared one silent premise: each compared figures within a single period, so an error that scaled an entire period passed all of them. At that point the work is not adding more checks; it is finding the premise the existing checks share, and building the one comparison none of them makes.

The limit, stated.

Recomputation proves consistency with the source data, not ultimate truth — if the input is wrong the same way twice, both computations agree. That is exactly why the trust state stays permanently visible instead of becoming a one-time stamp.

See it live: the trust ledger, untrusted measures included · the dated correction record · the full pipeline, stage by stage · the design decision behind it