IT DOCUMENTATION + RUNBOOK TEMPLATE TAHAI Web Services | Companion to “IT Documentation That Survives the Ticket” Use this as an editable starting point. Replace bracketed fields, remove fields that do not apply, and obtain the approvals required in your environment. This template is not authorization to inspect or change any system. Do not include credentials, tokens, private keys, or unrelated personal data. PART 1 — TICKET / CHANGE CLOSEOUT Record ID: [Ticket or change identifier] Title: [Affected service + observed problem] Owner: [Responsible engineer / team] Affected organization / site: [Approved identifier] System record: [Link to authoritative environment record] Related runbook: [Link and revision, or “new runbook required”] Visibility: [Restricted evidence / internal operations / client-facing] Observation time and time zone: [When the condition was observed] Record created: [When these notes were written] 1. INTENDED RESULT [Describe what the person or service should be able to do.] 2. REPORTED IMPACT [Who reported what, which systems were affected, and what was not yet known.] 3. OBSERVATIONS [Separate facts from interpretations. Include test context and evidence links.] Observation | Time / environment | Evidence reference | Limitations [ | | | ] 4. WORKING EXPLANATION [State the hypothesis and evidence supporting it. State what remains unproven.] Alternatives tested: [Tests and results] Alternatives not tested: [Reasons and remaining questions] 5. AUTHORIZED ACTION Approval reference: [Who authorized which change, when, and under what scope] Prior state: [Restricted evidence / configuration reference] Recovery preparation: [Known-good configuration and restore route] Actual action: [What changed; no secret values] Action time and time zone: [Timestamp] Deviation from plan: [None, or describe and document approval] 6. VERIFICATION Test | Expected result | Observed result | Who / where / when | Evidence [ | | | | ] Original user workflow retested: [Pass / fail / not tested, with details] Recovery step verified: [Pass / fail / not tested / not applicable, with reason] Limits of conclusion: [What this testing does not establish] 7. DOCUMENTATION FOLLOW-THROUGH System record updated: [Link / revision / reason not required] Reusable runbook updated: [Link / revision / reason not required] Client-safe summary: [What was completed and what happens next] Outstanding action: [Task + owner + due date + acceptance check] Closure decision: [Closed / partially resolved / monitoring by named owner / escalated; use the status that accurately describes the work] PART 2 — REUSABLE RUNBOOK Title: [Task or symptom, not only a product name] Runbook ID: [Stable identifier] Owner: [Team or role responsible for maintaining it] Version: [Revision] Visibility: [Who may read and use it] Last edited: [Date] Last reviewed: [Date + reviewer + review scope] Last executed/tested: [Date + operator + environment + result] Review triggers: [Configuration / software / ownership change; failure in use] Periodic review: [Risk-appropriate schedule] Replaces / replaced by: [Record link, where applicable] PURPOSE [The specific decision or outcome this procedure supports.] APPLIES WHEN [Required symptoms, supported versions, environment, and access scope.] DOES NOT APPLY WHEN [Known exclusions, wider outage conditions, unsupported versions.] PREREQUISITES - [Required role and approval] - [Authoritative configuration / system record] - [Approved tools and versions] - [Appropriate test context and communication plan] - [Secret-store reference if needed; never the secret itself] READ-ONLY DIAGNOSIS For each step record: Condition: [When to run this check] Action: [Precise authorized action] Expected result: [What the output should establish] Different / failed result: [Next test or escalation] Evidence: [What to retain and where] CHANGE GATE [Which additional approval is required before any modification?] [Which actions are expressly outside this procedure?] IMPLEMENTATION (ONLY WHERE AUTHORIZED) [Ordered steps, relevant parameters, dependencies, and expected results.] [Explain each command and its effects rather than supplying a bare command.] STOP / ESCALATE [Conditions requiring the operator to stop.] [Role / approved route for escalation.] [Information to provide without leaking secrets or excessive personal data.] RECOVERY [Rollback trigger, known-good state, restore procedure, required authority, validation after recovery, and who must be notified.] [Mark untested recovery steps explicitly; do not imply demonstrated recovery.] ACCEPTANCE [Original task + dependency checks + expected result + evidence to retain.] CLOSEOUT [Where to record the attempt, its result, anomalies, and needed documentation changes. Do not silently edit the runbook to match an unexplained outcome.] PART 3 — HANDOFF REVIEW Reviewer: [Authorized person other than the original author, where practical] Date / environment: [ ] Runbook revision tested: [ ] [ ] Correct system and procedure could be found without coaching. [ ] Scope, prerequisites, and permissions were understandable. [ ] Relevant authoritative records and evidence could be accessed. [ ] Steps and expected results were clear. [ ] Stop conditions and escalation route were usable. [ ] Required recovery instructions were reviewed and tested where appropriate. [ ] Original workflow verification was repeatable in the agreed context. [ ] Internal and client-facing access boundaries were tested. [ ] Secrets and unrelated personal information were excluded. [ ] Unresolved work has an owner and a defined next action. Defects found: [ ] Corrections made: [ ] Remaining limitations: [ ] Accepted by / scope of acceptance: [ ] Permission: You may copy and adapt this companion template for your own organization or project. It contains no supplied client data or credentials.