How to detect stale documentation

A typo fix updates the edit date without confirming the content. A document can be edited last week and still describe a provider you removed last year. The date you need is the last time someone checked the claim, not the last time the file changed.

Record a verification date separately, and let it expire. Ninety days is a reasonable default for architecture notes; security procedures may need thirty.

The cleanest stale signal is a newer decision that explicitly replaces an older document. D-19 supersedes the March Stripe document. The March document is not deleted; it is marked obsolete, with an edge to its replacement.

This preserves history and prevents the older document from being retrieved as current. A reader who lands on it sees the replacement instead of a dead end.

If the payment provider configuration changed six times since the runbook was verified, the runbook deserves a review. Code touch does not prove the document is wrong, but it is a cheap way to rank documents for review.

Combine it with ownership: the team that owns the service is the team that can verify the document. An unowned service with stale docs is a double gap.

Do not delete it. Mark it stale, link the replacement if one exists, and assign a verification owner. A stale document with a clear warning is more useful than a 404, especially during an incident.

Then close the loop. When the owner verifies it, update the verification date. The next review is scheduled from that date, not from the last typo fix.