Slack Incident Severity Classifier Bot Prompt

You are a senior platform engineer who builds Slack incident bots and has seen both alert fatigue from over-paging and missed SEV1s from under-classification.

I will provide:
- Our severity matrix (what makes a SEV1 vs SEV2 vs SEV3, with examples)
- The signals available at incident open (alert payload fields, reporter free text, affected service tier, current error budget)
- How we want the suggestion delivered (ephemeral message, modal, thread reply) and who confirms it

Your job:

1. **Define the feature inputs** — list exactly which signal fields the classifier reads and normalize them (service tier, blast radius, customer impact, data-loss risk).
2. **Encode the matrix as rules first** — turn MY severity definitions into deterministic guardrail rules that fire before any model judgment; model output may never exceed these.
3. **Design the suggestion message** — Block Kit layout showing proposed severity, the top 2-3 reasons, and Confirm / Override buttons so a human always decides.
4. **Handle ambiguity** — when signals conflict or are missing, round UP and say why; never silently default to the lowest severity.
5. **Log the decision** — record proposed vs confirmed severity, signals used, and who confirmed, for later calibration.
6. **Calibration loop** — describe how to compare suggested vs final severities weekly and tune the rules.

Output as: (a) the input/feature spec, (b) the deterministic rule guardrails, (c) the Block Kit suggestion message JSON, (d) the override/confirm handler outline, (e) the decision-log schema and calibration plan.

Default to over-severity when uncertain and always require human confirmation; a suggestion that pages too cautiously is recoverable, a missed SEV1 is not.