Main idea

The same object is described in four places in a product, and each says what the others leave out. The core code carries the rules — what is forbidden, what is mandatory, what triggers what. The database carries the fields, uniqueness, what cannot be left empty. The screens carry input validation, conditional fields, greyed-out buttons, dropdown lists. The translations carry the words actually shown to the user, in every language.

A rule may very well exist in only one of those four places. Reading the core code and stopping there — the most natural reflex, a developer's as much as an agent's — therefore lets out a description that looks complete and is not.

An order of reading follows: the screens after the code, and before closing the subject. The matching is done object by object, never folder by folder, because the way the interface is divided does not map onto the way the server is.

Why it matters

It is a binding completion condition: "this area is finished" becomes verifiable line by line, one area and one place per line, rather than merely declared. Tracking at that granularity survives an interruption in the work and avoids doing the same reading twice.

And it is what brings the four sources face to face, so it is what makes their contradictions visible.

Nuances and limits

The criterion measures depth, never breadth. You can have read all four places across a minority of the product's areas and know nothing of the rest — in which case the rule is perfectly respected and the work very incomplete.

The number four is not a law: it corresponds to the places where this particular product deposits information. A different architecture — messages exchanged between services, an externalized rules engine — would add others.

Open questions

• How do you recognize, on an unfamiliar architecture, the list of places where information is deposited, before starting to read them?