The Staleness Problem

Staleness is the gap between what the knowledge base says and what is currently true. It accumulates silently and asymmetrically: content becomes stale immediately when the underlying reality changes, but the knowledge base does not know the reality changed. The only mechanisms that detect staleness are: scheduled reviews (detect staleness on a fixed schedule), event-triggered reviews (detect staleness when a known change event occurs), and user reports (detect staleness when a user discovers wrong information).

All three mechanisms are reactive. The goal is to catch staleness before a user acts on wrong information — ideally before the wrong information is even read.

1. Staleness Signals Not all stale content is equally dangerous. Prioritize detection based on: access frequency (high-traffic content that is stale reaches more users), content type (runbooks are higher risk than decision records — acting on a wrong procedure is worse than reading an outdated architectural rationale), and domain volatility (infrastructure content in a team doing weekly deployments goes stale faster than compliance content in a stable regulatory environment).
2. Automated Staleness Detection Three automated signals: review age (content past its scheduled review date is flagged as potentially stale — this is calendar-based), broken links (links within content to external systems, documentation, or other content items are checked weekly; broken links indicate the referenced resource has changed), and semantic drift (for systems with embeddings, compare the content's embedding to the embedding of recently updated content in the same domain — significant drift from the current centroid indicates the content may be out of step with current practice).
3. User-Reported Staleness Every content item should have a one-click "Something looks wrong" mechanism. The report goes to the domain steward with context: which item, which user, what they were trying to do, and (optionally) what is wrong. User reports are the highest-signal staleness detection mechanism because they identify content that is both stale and actively misleading users. A runbook that is outdated but never accessed generates no user reports; a runbook that is outdated and used daily generates reports immediately when someone follows it and gets a wrong result.
4. System-Change Triggered Audits When a significant system change is made — a new tool replaces an old one, an API changes, a process is redesigned — run a targeted audit of all content that references the changed system or process. This requires tagging content with system and tool references at publication time. The audit identifies every item that may now be inaccurate due to the change and routes them to the steward for expedited review. Without this mechanism, system changes silently invalidate existing documentation until users discover the discrepancy.