Documentation Drift
The gradual divergence between written documentation and the product it describes. Different framing of the same problem as specification drift, more common in everyday usage.
Documentation drift happens to almost every team eventually. A doc is written, the product changes, the doc isn't updated. Repeat for every release for two years. By the time someone needs an answer, the documentation reflects a version of the product that no longer exists. Confidence in the docs collapses, and teams revert to asking the one engineer who remembers how things actually work.
It isn't a tool problem. Notion drifts. Confluence drifts. Google Docs drifts. The cause is structural: documentation is a separate, parallel artefact that depends on a human remembering to keep it current, and humans rarely do. Atlassian's 2025 research found teams waste 25% of their working week searching for answers that should already be documented — a direct consequence of drift eroding trust in existing docs.
The only fix that scales is to remove the human update step. If documentation is derived from the source of truth (the code, in the case of product behaviour) and regenerated automatically, drift can't occur. That's the structural insight behind a living product specification.
Related Terms
The gap that opens between a written specification and the product it is meant to describe — widens with every release that nobody remembers to document.
Documentation that is structurally incapable of falling out of sync with the product, because it is derived from the code rather than written separately.
The accumulated cost of outdated, missing, or unreliable documentation. Like technical debt, but for the gap between what your product does and what your team can describe.
Further Reading
See it in practice
The Specsight demo shows real scenarios, features, and a complete living product spec — generated from an actual codebase.