The examples and architectures in this series are my personal educational, non-commercial experiments; they are not an offer of IT or consulting services.
Post #7 ended with a fix: a sanity-check rule that holds a report for manual review whenever a number moves more than a set threshold from the prior period, instead of sending it straight to an inbox. Three weeks later, that rule did exactly what it was built to do. It just flagged the wrong thing — or rather, it flagged something that turned out to be completely fine.
The alert, the numbers, and the explanation below are a composite illustration, put together from patterns I've seen repeat across different projects; they don't describe a specific company, dataset, or person.
Three weeks later
What the alert flagged
The rule watches a handful of core figures and compares each new one to the prior period. One morning, it held a report before it went out: days of cash on hand had jumped from 45 to 71 in a single week — a 58% move, well past the variance threshold set after Post #7. On paper, that's exactly the kind of number the rule exists to catch. A jump that size, unexplained, is either very good news or a sign something in the data is broken.
| What the alert flagged | What was actually true |
|---|---|
| Days of cash on hand: 45 → 71 in one week, above the review threshold | A client had paid a six-month retainer upfront for a project starting in Q4 — real cash, correctly recorded, just unusually timed |
| The same account was flagged again the following week, still elevated | Not a new anomaly — the same deposit, still sitting there, exactly as expected |
Why it looked like a problem
The rule doesn't know why a number moved, only that it moved more than a set percentage. It has no concept of "expected but unusual" versus "unexpected and wrong" — every threshold breach looks identical from the inside. Runway math has no way, on its own, to tell an early payment apart from a modeling error, a duplicate entry, or a metric that's simply now measuring something different than the number it's being compared to.
A system that cries wolf costs you the same trust as one that misses the wolf — it just spends it more slowly.
What almost happened
By the second flag, the instinct in the room was to mark the whole rule "too sensitive" and turn the threshold down — which would have quietly reopened the exact gap Post #7 was meant to close. That's the real risk in a false alarm: not the twenty minutes spent checking it, but the erosion that makes people stop checking the next one, real or not.
What changed after that
Two adjustments went in. First, a short list of known, recurring-but-irregular events — advance payments, insurance renewals, annual license fees — that get tagged at the point of entry, so the threshold rule can treat them differently from an unexplained jump. Second, every held alert now has to carry one line explaining what changed before anyone acts on it, instead of just a number and a red flag. If nobody can write that line yet, the report stays held until someone can.
Why a false alarm can matter more than the mistake it's guarding against
In my experience, an alert that's wrong once teaches the system almost nothing on its own — but it teaches the person reading it something they don't forget: that this particular flag isn't always worth trusting. A missed error costs you once, when it's caught late. A false alarm can cost you every time after it, quietly, in the form of an alert nobody opens anymore.
Follow the series
Post #9 looks at a different blind spot — one measured in exchange rates, not dates.