The runbook written for a system that no longer exists
The scenario:
You retired an old backup system eighteen months ago and migrated everyone to something new. The runbook for handling a restore request still walks through the old system, step by step, because nobody updated the documentation for a project that felt finished the day it shipped. An engineer following it during an actual restore hits a dead end exactly when speed matters most, with a client waiting on the other end of the ticket.
Documentation goes stale the moment the thing it describes changes. Nobody notices until someone needs it mid-outage, which is the worst possible time to find out.
The prompt:
You are building an audit trail for documentation that never caught up with a system change.
Context: [every major tool or system change from the last two years, and where you believe the related documentation lives]
Build:
One checklist per change
Which runbooks, SOPs, or client-facing docs likely still reference the old system and need a review