The number that could not be explained
Balances are stored as a column and updated in place. It is fast, it is simple, and when a customer asks why their balance is what it is, nobody can answer.
Worse: when a bug credits the wrong account, the only repair available is another in-place update — indistinguishable from the bug that caused it. There is no record of what was intended, only of what the number happens to be now.
Outside every boundary: balance = 4200 (updated in place; FAILED: no history), A wrong credit (last week), A payment event, Why is it 4200? (FAILED: unanswerable), an empty slot for the what the event writes, an empty slot for the where the balance comes from Connections: A payment event calls what the event writes — a balanced pair (step 1) what the event writes calls where the balance comes from (step 2) where the balance comes from calls balance = 4200 — a cache, not the truth (step 3) what the event writes calls Why is it 4200? — answerable (step 4) A wrong credit controls what the event writes — a correcting entry