AI incident response runbook

You are an incident response lead. Draft an AI incident runbook tailored to the system below. The runbook must be usable at 2am by someone who is not the system's original builder.

CONTEXT
- The AI system: {{system_description}}
- Where it touches users or customers: {{user_surface}}
- Who's on-call (roles, not names): {{on_call_roles}}
- Common failure modes you've already observed: {{known_failure_modes}}

OUTPUT (runbook, in this order)

**Trigger conditions.** Bullet list of specific events that constitute an "AI incident" and require this runbook to be opened.

**Severity tiers.** Three tiers. For each, plain-English criteria + max time to declare + who must be notified.

**Step 1: Detect and confirm.** First 15 minutes.
- What to look at first.
- The single command, dashboard, or log to check.
- How to confirm this is a real incident vs. a transient blip.

**Step 2: Contain.** Next 30 minutes.
- The kill switch. Name it. Where it lives. Who has access.
- The fallback path (e.g., route to human queue, surface friendly error).
- The decision: when to flip the kill switch vs. when to keep running with monitoring.

**Step 3: Notify.** Within 60 minutes.
- Internal notification list and method.
- Customer notification triggers and language template.
- Regulatory notification triggers, if any.

**Step 4: Investigate.** Hours 1 to 8.
- The five questions to answer in the incident channel.
- The data sources to capture before they roll off (logs, prompts, model outputs, downstream effects).

**Step 5: Root cause + remediation.** Days 1 to 5.
- Five Whys structure.
- The artifact: a written root cause document with the four sections (what happened, why, what we changed, how we'll catch this earlier next time).

**Step 6: What changes permanently.** This is the section most runbooks skip.
- The new monitoring or alert added.
- The change to the AUP, vendor contract, or model selection.
- The team training that gets added.

**Communication templates.**
- Internal "we are investigating" note (Slack-ready, 4 lines).
- Customer-facing acknowledgment (email-ready, 8 lines).
- Customer-facing resolution (email-ready, 10 lines).

VOICE
- Operational. A tired engineer follows it.
- No em-dashes.
- No "leverage," "unlock," "navigate," "robust," "seamless," "cutting-edge."