Reference
What a runbook covers
A workflow nobody can operate without its builder is a dependency, not a deliverable. The runbook is what turns one into the other.
Illustrative workflow using synthetic data
Why a runbook matters
The firm operates the workflow. That requires knowing how to start it, how to stop it, what normal looks like, what to do when something fails, and who to call at each provider. A runbook reduces dependency on Gulf & Ponte; it does not eliminate key-person risk, and this page will not pretend otherwise.
The completed runbook is a delivery artifact for the firm’s workflow.
Contents
The table of contents of a delivered runbook, at section level.
- Workflow purpose and owner
- Systems and external providers
- Start and stop procedure
- What normal operation looks like
- The review queue
- Exception handling
- Failed-job recovery
- Access model and credential references
- Logging and where to find it
- Retention notes
- Provider support contacts
- Change process
- Offboarding and shutdown
- Known limitations
- Revision history
An illustrative excerpt
From the exception-handling section. Illustrative wording only; the real entries name the firm’s own systems, queues, and owners.
“A document that cannot be classified with confidence is held in the exception queue and does not proceed. The workflow owner reviews the queue at an agreed interval, resolves or reclassifies each item, and records the outcome. Nothing clears the queue automatically.”
Recovery procedures, access patterns, and the operational logic behind each step are part of the delivered document rather than this outline.
What is never in it
Credentials, tokens, taxpayer documents, and return information are never recorded in this document. The access inventory names where a credential lives and who controls it — the location and the owner, not the secret itself.