Find Drift and Stale Definitions

The best evidence for this is a real document that says so about itself. A specification was re-read against the live implementation and two things it had claimed turned out to be wrong. Both had been believed, and acted on, for months.

Nothing failed. Nobody was careless. The implementation changed and the document did not, which is the normal behavior of documents.

So the check is: re-read the specification against the live behavior, on a schedule. Not review the document, which finds typos. Compare it to what the system actually does.

Staleness is per thing, and needs a sweep

Freshness is not one global setting. Different definitions, rules, and cached values go stale at different rates, so each gets its own threshold.

And a threshold on its own is a hope. What turns it into a guarantee is a scheduled sweep that finds everything past its threshold and produces a list. Without the sweep, the threshold is a number nobody evaluates.

Rules and definitions need review dates

Some things expire: a rule scoped to a fiscal period is only correct inside it. Most things do not expire and still need a review date, which is a freshness commitment about the definition itself, separate from the freshness of the data it describes.

A definition nobody has looked at in two years is not automatically wrong. It is automatically unverified, and the review list should say which.

Record the reason, so the decision can be revisited

A real system records that a particular vendor choice was made for cost, that quality was comparable, and that it can be reversed at any time. Read what that buys: when pricing moves, and it will, somebody can revisit the decision knowing exactly what it was based on.

A decision whose reason was recorded can be revisited when the reason changes. A decision whose reason was not recorded becomes permanent by default, and everybody assumes there was a good reason, which is how systems accumulate choices nobody would make again.