Main idea

Three situations, one mechanism. An order's status derived from a few dates and the state of its lines, recomputed in every screen, with no central rule: two screens end up disagreeing, and nobody knows which one is right. A customer's balance, which isn't a number stored somewhere but the result of a calculation over the invoices, the payments, the credit notes and the adjustment entries: every feature that "reads the balance" gets the wrong object and returns a slightly different figure, depending on which movements it thought to include. A person's access rights, arising from their role, the plan subscribed to, the options enabled, a trial-period restriction, their subsidiary's scope and a list of exceptions, with nowhere saying how they are computed.

In all three cases the notion exists for users and exists nowhere as a definition. It is therefore reconstituted at every use, and every reconstitution is slightly different — not out of negligence, but because nothing lets you compare yours to a reference.

Three screens, three balances: the discrepancy isn't a one-off defect, it is the normal consequence of a notion with no home.

Why it matters

This shifts how you handle such inconsistencies: fixing the offending screen settles nothing, since the next one will start over. What is missing is a written definition, and the first deliverable is a sentence, not a patch.

It also gives you a cheap detection signal: a notion users talk about every day and that nowhere in the product defines is almost always one of these.

Nuances and limits

Writing the definition isn't enough to unify the behaviour: as long as each screen keeps its own calculation, the definition is only an expectation, and the discrepancy merely becomes observable — which is progress, but not a fix.

And some variations are legitimate: an accounting balance and a commercial balance may rightly differ. In that case there are two notions to name separately, not one notion to unify.

Open questions

• Does a definition written outside the code hold up over time without a mechanism that confronts it with actual behaviour?