Write the incident handoff and game-day record

Verifiedon 2026-08-022026.7.1

Write for the next operator, not the author

A handoff is a control surface. It should let someone who was not present answer five questions quickly: what changed for users, what is verified, what remains uncertain, what decision was made, and what must happen next. “Issue resolved” is not a handoff. “Rollback to 2026.7.1 restored gateway readiness; synthetic channel acceptance still fails; channel owner B to investigate before 16:00 UTC” is.

The record must be blameless and specific. Name actions, timestamps, systems, and decision owners; do not assign character judgments. Separate verified facts from hypotheses and decisions. Link to redacted evidence instead of pasting raw logs. Keep the course scope visible: stable 2026.7.1, upstream revision 2d2ddc43d0dcf71f31283d780f9fe9ff4cc04fe4, and primary docs reviewed 2026-08-01 UTC. The current Gateway diagnostics export says exports contain sanitized status, health, log summaries, config shape, and stability data, but still must be treated like secrets until reviewed.

1. Impact and timeline anchor the record in a bounded time window.
2. Evidence and decision show what was checked and why the action was chosen.
3. Recovery status must say proven, degraded, or unknown.
4. Residual risk, owner, and review date prevent an incident from disappearing into a closed ticket.

The game-day pack

For this course, the handoff is the terminal page of a recovery game day. Assemble these artifacts in an approved record:

1. Change review: target version, source receipt, risk score, acceptance checks, and stop conditions.
2. Recovery baseline: version, config shape, state boundaries, RPO/RTO, backup ID, and restore proof.
3. Run sheet: entry gate, one attributable change, command result, evidence, failure signal, and decision.
4. Rollback proof: trigger, freeze time, preserved evidence, restore action, checks, and residual uncertainty.
5. Incident record: impact, timeline, facts, hypotheses, actions, and affected boundaries.
6. Handoff: current state, decision, residual risk, owner, next action, and review date.

A pack is not complete because every file exists. Cross-check links, versions, timestamps, snapshot IDs, and the workflow that actually ran. If a source or receipt is stale, mark the limitation instead of claiming current support. The committed 2026.7.1 game-day receipt is the course’s redacted reference pack: it retains package integrity, command outcomes, rollback comparison, health checks, and the exact pinned-CLI limitation while omitting disposable logs, archives, and synthetic credentials.

Worked example: concise and honest

GAME DAY GD-017 · synthetic sandbox · 2026-08-01 UTC
Impact: none to production; sandbox channel acceptance failed after the approved update.
Timeline: baseline pass 14:00; update complete 14:08; acceptance failure 14:12;
freeze 14:14; restore complete 14:27; post-restore gateway health pass 14:29.
Verified: stable 2026.7.1 active; config lint has no blocking findings; state snapshot restored;
WebChat synthetic workflow passes.
Unproven: synthetic channel adapter still fails; no real recipient test was attempted.
Decision: defer promotion. Channel owner B investigates adapter compatibility in a fresh sandbox.
Residual risk: recovery is proven for gateway/config/state/WebChat, not for the channel adapter.
Owner: B. Next action: compare adapter logs against the release receipt by 16:00 UTC.
Review: operator A at 16:15 UTC; source scope expires 2026-08-28.
Evidence: redacted bundle E-017; backup snapshot S-017; run sheet RS-017.

Notice what is missing: blame, secret values, customer messages, and a confident root cause. That omission is a strength. The Doctor reference distinguishes read-only lint and post-upgrade probes from repairs; the Restart recovery reference describes automatic recovery and safety valves; the Database schemas reference explains why a downgrade cannot be treated as a data downgrade. Link those primary sources in the evidence index, but do not copy their whole pages into the handoff.

E-017 | doctor --lint --json | 2026-08-01T14:29Z | exit=0 | redacted=true | proves=lint snapshot

Grade the pack against evidence, not polish

Use the course capstone rubric:

• Recovery baseline — 35%: version, state boundaries, owner, recovery objectives, verified artifact, and restore acceptance.
• Rollback rehearsal — 35%: one controlled change, observable trigger, preserved evidence, approved restore, and same-path validation.
• Incident handoff — 30%: verified impact, evidence links, decision, residual risk, owner, next action, and review date.

A missing restore proof is a fail for the recovery criterion even if the document is beautifully written. A successful process start is not enough. A pack that contains raw credentials fails the privacy boundary and must be withdrawn, redacted, and reviewed again. A stale source receipt means the version claim must be narrowed until an independent technical review refreshes it.

Lab: peer-readable game day

Run a complete synthetic game day from the earlier lessons. Give your peer only the pack, not your terminal history. Their job is to answer: what was the impact, what is proven, what is not proven, who owns the next action, what is the stop condition, and when is the next review? If they cannot answer in two minutes, the handoff is not ready.

Then perform a handoff audit:

1. compare every version, timestamp, snapshot ID, and evidence location across artifacts;
2. check that all commands are from the installed CLI or cited current primary docs;
3. scan for tokens, authorization headers, real payloads, account IDs, private hostnames, and local usernames;
4. label facts, hypotheses, decisions, and unknowns;
5. verify the next owner accepted the action and the review date fits the critical 30-day freshness SLA;
6. record any limitation and the exact action that would close it.

Expected output is the complete game-day pack plus the peer’s six-answer review. Failure cases include contradictory timestamps, a missing source receipt, a handoff that says “resolved” while an acceptance check failed, or a learner who cannot reproduce the next step. Roll back by withdrawing the unredacted draft, preserving the safe evidence pack, and issuing a corrected version with a change note. Never delete the history of the original error.

Checkpoint: a polished but unsupported claim

A recovery pack says “all systems healthy,” but one claim has no evidence receipt. The decision is hold review, not publish or close. Keep the run history. Remove or qualify the unsupported claim, route it back to technical review, and preserve the fact that the check was missing. Execution success and publication approval are separate gates.

Final course artifact

Submit the recovery game-day pack defined in recovery-game-day-pack: baseline, verified backup and restore proof, release-risk review, run sheet, rollback proof, incident record, and handoff. Include a text alternative for the diagram and a short publication recommendation: hold draft until the independent reviewer validates release-specific commands, source receipts, and current version scope.

Check your understanding

A synthetic rollback restored gateway readiness, but the handoff contains no evidence receipt for one channel acceptance check. What should the operator do before closing the incident? Answer in three parts: the decision, the missing evidence, and the owner plus review date. A strong answer holds publication, names the failed or unknown check, and routes the gap to a named owner without deleting the run history.

The course assessment retains its structured freshness gate; scenario questions test evidence, rollback, and residual risk. Primary receipts: Diagnostics export, Doctor, Restart recovery, Database schemas, and v2026.7.1 release notes.