The work has no trigger
A product change has an owner, a branch, a review, and a deploy. The documentation consequence usually has none. It depends on somebody remembering that a page once described the thing that moved.
That makes stale documentation a coordination failure. Asking writers to care more does not create the missing link between a code change and the page it affects.
Age is useful, but evidence is better
A review date catches quiet decay. It cannot tell whether yesterday’s pull request renamed a field shown on three pages. Repository and OpenAPI changes provide a stronger signal because they describe what moved.
- Use review intervals for facts that age predictably.
- Map code and API changes to the pages that mention them.
- Use failed searches and reader feedback as evidence of missing answers.
- Show why a page was flagged so a writer can decide quickly.
Build maintenance into publishing
The useful loop is simple: write, review, publish, observe, and return with evidence. A page should carry an owner and a review policy. A change should produce a small queue of plausible documentation work, not a generic reminder to audit everything.
The goal is not to make every signal automatic truth. The goal is to make forgetting less likely and reviewing cheaper.