The Living Document — Version Control, Review Cycles, and Knowing When to Retire

Every document is accurate at the moment of its creation and becomes progressively less accurate as the world it describes changes. This is not a documentation failure — it is the nature of documentation in a changing environment. The discipline is not to prevent documents from becoming outdated (impossible), but to detect when they have become outdated and act appropriately: update them when the underlying process has changed, or retire them when the process they document no longer exists.

The living document is not a metaphor for constant editing. It is a structured approach to document lifecycle: defined review triggers, version control that makes the history visible, retirement criteria that remove outdated content before it misleads practitioners, and an update process that is low enough friction that owners will actually complete it.

1. Version Control That Is Actually Used Version control for documentation does not require complex systems. It requires a version number in the document header, a change log that records what changed in each version and why, and a clear designation of which version is current. The practitioner who finds an outdated version should immediately be able to identify it as outdated (the version number does not match the current version) and find the current version (the index points to it). Simple version numbering — v1.0, v1.1, v2.0 — is sufficient. The complexity is in the discipline of using it consistently.
2. Review Triggers Beyond Cadence Scheduled review cadences catch slow drift. They do not catch sudden changes. Every documentation system needs trigger-based review criteria: what events require immediate document review regardless of the scheduled cycle? A process change. A system update. A regulatory change. A pattern of practitioner errors that suggests the SOP is being followed incorrectly. The owner of a document should receive notification when any trigger event occurs, and the review should happen within a defined window — typically two weeks for critical procedures, four weeks for less critical ones.
3. Retiring Content Deliberately Document retirement is the most neglected element of documentation lifecycle management. Documents are easy to create and almost never deliberately deleted. The result is documentation systems that grow in volume, decline in signal-to-noise ratio, and eventually become so cluttered that practitioners stop trusting them. A document should be retired when the process it describes has been superseded, when the system it documents no longer exists, or when the need it served has been absorbed into another document. Retirement means removal from the active documentation system — not archiving where practitioners might still find it.
4. The Retirement Decision Before retiring a document, ask three questions. First: is there any practitioner who still relies on this document for a process they are still performing? If yes, update rather than retire. Second: is the information in this document fully captured in a current document? If yes, retire and link to the current document from any referencing pages. Third: is this document being kept for historical or regulatory reasons? If yes, archive with an explicit 'archived — not current' label. If the answer to all three is no, delete it. Deleted content cannot mislead practitioners.

Documentation that is not maintained is not documentation. It is organizational debt — accumulating interest in the form of errors, inconsistencies, and practitioners who have learned to work around the system rather than with it. Maintain what you create. Retire what you cannot maintain. The document that does not exist cannot mislead anyone.

— QUILL

The BW-201c course closes with a final principle that runs through all three modules: documentation is a form of respect. Client deliverables that transfer knowledge without requiring the consultant to explain them respect the client's time and capability. Playbooks and SOPs that actually work respect the practitioners who follow them. Wiki articles that are accurate and findable respect the people who need them at the moment of need. Documentation that is created and forgotten, that is thorough but inaccessible, that is accurate when created and outdated six months later — that documentation respects no one. Write it to be used. Maintain it to remain usable. Retire it when it no longer is.