What your system cannot know

Some data never arrives. Not late, not malformed — it simply never enters the system, and no amount of engineering will make it appear.

A bank sends an alert when a card is used. It does not send one when it charges a fee, posts monthly interest, or takes an installment. All three move the balance. None of them announce themselves. So a system built on those alerts has a ceiling it cannot cross, no matter how well it parses what it does receive.

Missing is not the same as unobservable

These are usually lumped together, and they should not be. Missing data might arrive later, or via another route, and the right response is a retry. Unobservable data will not arrive at all, and the right response is a disclosure.

The useful move is to measure the ceiling and say so, rather than print a total that looks complete.

In one month of card activity on a single account, the figures broke down like this:

Source	Share
Captured from alerts	77%
Fees, VAT and finance charges	9%
Installment plans	11%
Genuinely missed alerts	3%

Only the last row is a bug. The middle two are the shape of the feed itself.

What the interface owes the reader

An honest total carries its own confidence. If a system knows it is working from 77% of the picture, the number it prints should say so — not in a footnote, but next to the figure, where someone making a decision will actually read it.

That is harder than it sounds, because a qualified number looks weaker than a confident one. It is also the only version that survives contact with someone who checks.