Main idea

When a check is enforced only by the interface — a discount cap verified in the entry form and nowhere else — only two readings are possible, and both are gaps.

Either it is a genuine business rule in the wrong place: it should live where the rules live, and its presence in the screen is a design flaw to arbitrate. Or it can be bypassed — through a file import, through the interface the product exposes to outside developers — and it is then a defect with a security dimension: what the screen forbids, another path allows.

The reverse case is handled the same way. A rule enforced by the core code that the screen does not reflect produces an incomprehensible refusal: the user sees their action rejected without seeing what they did wrong.

Why it matters

It turns reading the screens — usually relegated to the end of the run, when it is done at all — into a gap-finding machine. The return is high because the question requires no judgment: you simply observe that a rule has no twin on the server side.

It also gives an argument for not skipping that reading when time is short: it is the part of the product that pays the most per hour spent.

Nuances and limits

"Almost always": an input aid with no business bearing — a suggested date format, a field hidden to declutter the screen — is not a rule and does not become a gap.

Bypassing assumes another path is genuinely open. On a product with no import and no external interface, the first case — the misplaced business rule — is left alone in the running.

Open questions

• Once the rule has moved to the server side, what becomes of the input check: deliberate duplication for convenience, or a source of future divergence?