Main idea

Describing software means fixing a moment: one version of the code, and everything that runs with it — the database as it is at that version, the screens of that version, the translations of that version. That is the snapshot, and it defines what is allowed in.

A database export produced a few months earlier nevertheless looks usable: it describes the same product, give or take. In reality it describes an older product, and the "give or take" is precisely what you were looking for. Across a whole area, objects present in the code had no corresponding table in the export — and the conclusion drawn was that they did not exist.

The rule is not "check the date before concluding", because that kind of vigilance does not hold over time. It is more radical: a source from another date is replaced with an up-to-date version, or you do without it.

Why it matters

This is what prevents a silent error. An out-of-date source produces no error message: it produces an absence, and an absence reads as information — "this object does not exist" — when in fact it says nothing.

And the rule can be enforced without judgment: every source carries its version, or it leaves the perimeter. It is a condition of admission, not a precaution when reading.

Nuances and limits

The requirement applies only to sources meant to describe the state of the product. Material that carries what people say — interview notes, tickets — is dated by nature and keeps its value: it does not describe the product, it describes a use.

The constraint has a real cost: rebuilding a source at the right version takes time, and the temptation to use the one already at hand comes back with every area.

Open questions

• How often should the snapshot be retaken, given that every drift progressively turns the available sources into inadmissible ones?