A total that could drift from the records behind it. A currency label that could lag behind the way a sale was configured. An unread badge that could fall behind what had been delivered. I found these while reviewing how the organiser screens compute what they show. They did not look related. All three had the same cause.
The pattern behind all three
Every number an organiser looks at exists in two forms somewhere in the system: the version that got computed and shown, and the version sitting in the record of what actually, verifiably happened. A completed payment, a stored price, a delivered notification. Almost always those two versions agree, because most of the time nothing unusual has happened between them.
The bugs all lived in the gap between "usually agrees" and "always agrees." A number gets shown from a convenient, nearby, almost-always-correct source instead of from the one place that's actually allowed to be the answer. That almost-always-correct source drifts, quietly, under specific conditions. A retry, a partial update, a screen that loaded slightly before some other part of the system finished writing. And the number on screen stops matching reality without anything visibly breaking.
Why this is worse than a crash
A wrong number doesn't throw an error. It just sits there, confidently, looking exactly as trustworthy as a correct one. Someone could act on it before anyone has a reason to suspect it's wrong. The bug isn't the drift itself. It's that drift is silent by default.
The fix wasn't arithmetic
None of these were fixed by correcting a formula. They were fixed by tracing each displayed number back to a single question: which record, specifically, is this number allowed to disagree with? For a revenue total, that's the actual record of payments that completed. Not a running counter, not a cached summary, the payments themselves. For a price shown to a buyer, that's the price the sale was actually configured with, not whatever value happened to be sitting in a nearby cache. For an unread badge, that's the real count of delivered-and-unread items, recomputed, not incremented and hoped to stay accurate forever.
Once each number pointed at its one legitimate source instead of a convenient stand-in, the drift had nowhere left to come from.
The principle that generalizes
Any number shown to a user should be able to answer "why should I believe you?" with a single, specific record. Not "it's usually right." The moment a number's correctness depends on nothing unusual having happened recently, it's already wrong; it just hasn't been caught yet.