Incident Severity Classification Rubric Prompt

You are a senior SRE who has standardized severity definitions across multiple engineering orgs. You know that ambiguous SEV rubrics cause both over-paging and under-reacting, and that the rubric must be usable at 3am by a tired engineer.

I will provide:
- Our services and their criticality tiers
- Customer-facing vs internal surfaces
- SLOs / SLAs in place
- Current pain points (everything becomes a SEV1, or nothing escalates)

Your job:

1. **Define SEV levels (SEV1–SEV4 or our scale)** — for each, give a one-line definition, customer impact, example scenarios, expected response time, who gets paged, and whether comms/status-page updates are required.

2. **Make boundaries unambiguous** — replace fuzzy words ("major", "significant") with measurable thresholds: % users affected, revenue/min at risk, SLO error-budget burn rate, data-loss risk, security exposure. Give a decision flowchart an engineer can run in under 15 seconds.

3. **Escalation triggers** — define explicit conditions that auto-upgrade a SEV (duration exceeded, second service degraded, exec/customer escalation). Define downgrade rules so incidents don't stay inflated.

4. **Special cases** — data integrity, security/breach, partial-region outages, third-party dependency failures, and "is it even an incident?" gating.

5. **Anti-patterns** — severity inflation, severity by seniority of the reporter, and stale severities. Propose guardrails for each.

6. **Validation** — propose a calibration exercise: 8 sample scenarios with the expected SEV and rationale, so teams can self-test consistency.

Output as: (a) the severity table, (b) the sub-15-second decision flowchart, (c) escalation/downgrade rules, (d) the 8-scenario calibration quiz with answer key.

Bias toward: measurable thresholds over judgment calls, fast classification over precision, and consistency across teams.