Main idea

When the code says one thing and the database or the screen says another, the first reflex is to blame the dates: one of the two is behind the other, there is nothing to conclude. That reflex has a perverse effect — it files as a methodological artifact what is in fact the result you were after.

If both statements come from the same moment of the product — the same version, in production — no lag is involved. The product contradicts itself: a uniqueness constraint the business denies, an input check no server-side verification backs up, a field that is mandatory on screen and optional in the database. That is exactly the kind of divergence a cross-reading is meant to surface.

Hence the precaution of order: date the sources first, so that any remaining contradiction belongs to the product and not to the observation setup.

Why it matters

It turns a methodological nuisance into a return. Most of a reference model's value does not come from the rules it copies down cleanly, but from the places where two parts of the product do not say the same thing — each becoming debt to arbitrate or a defect with a security dimension.

It also stops the description being "smoothed over": faced with two contradictory statements, the temptation is to keep one and move on, which erases the find.

Nuances and limits

The rule demands exemplary discipline on dating, failing which it produces the opposite error: taking a lag between sources for an inconsistency in the product, and opening gaps that do not exist.

And not every contradiction has the same status: a difference between two applications may be a deliberate choice of scope rather than a defect, provided that choice is written down somewhere.

Open questions

• What share of these contradictions is knowingly accepted by the teams, and how do you tell a tacit trade-off from a defect nobody ever saw?