Severity Matrix Activation¶

Classification tool — instantiates Acute Stabilization Command

Applies a pre-agreed severity grid to classify an incident's blast radius at the moment it is detected, and that grade — not a judgment call — is what trips the command regime on.

The first question in any acute incident is how bad is this? — and the worst place to answer it is by argument, in the moment, while harm spreads. Severity Matrix Activation answers it mechanically. A grid, agreed in advance, maps observable signals — how many are affected, whether a critical path is down, whether harm is reversible, whether data or safety is at risk — onto a small set of discrete grades (SEV1, SEV2, …). The grade is the whole point: it is simultaneously the trigger that declares an incident exists and the sizing that decides how much command machinery switches on. What makes this mechanism distinct from everything downstream is that it never touches the response itself — it classifies, and the classification pulls the switch.

Example¶

A SaaS platform's monitoring flags a spike in login failures. Instead of debating whether this "counts," the on-call engineer reads the matrix: login path down and >25% of customers affected lands squarely in SEV1. That single classification does the work — it auto-pages an incident commander, opens the acute phase, sets a tight update cadence, and grants the emergency authority the regime needs. Had the same signal been one cosmetic feature failing with an easy workaround, the matrix would have read SEV3: logged, handled by normal on-call, no command regime at all. The team spent no time arguing about how seriously to take it; the grid decided, and the grid's decision is what everyone downstream inherits.

How it works¶

What distinguishes this from a generic "assess the situation" step is that the mapping is fixed before the incident and the trigger is a bright line, not a feeling:

Observable axes, not vibes. Severity is read off pre-chosen dimensions (reach, criticality, reversibility, data/safety exposure) so two people classify the same event the same way.
Discrete grades with bound-in defaults. Each grade carries its own downstream package — who is paged, what authority opens, how often to update — so declaring the grade configures the response in one move.
A bright-line trigger. Crossing the threshold is the declaration of an incident; there is no separate "should we call this?" conversation.

Tuning parameters¶

Number of grades — more levels give finer response-matching but blur the boundaries and slow classification; fewer levels are decisive but coarse.
Axis set — which impact dimensions the grid reads; the wrong axes classify confidently on the wrong thing.
Trip thresholds — how much impact crosses each line; set low and you cry wolf and exhaust responders, set high and real incidents run un-declared.
Activation mode — automatic on threshold vs. human-confirmed; automation is fast but brittle to bad signals.
Re-grade rules — whether and how a live incident is upgraded or downgraded as its blast radius changes.

When it helps, and when it misleads¶

Its strength is removing hesitation from the most time-critical moment: it converts "is this bad enough to escalate?" into a lookup, makes escalation legible and consistent, and ensures the amount of command machinery matches the size of the harm.

Its failure modes come from the grade being consequential. Because a SEV1 carries real overhead and visibility, there is steady pressure to under-classify — to log a genuine crisis a notch too low to avoid waking people — and occasional pressure to over-classify for attention. Axes that don't capture the harm that actually matters produce confident mis-grades, and a grade set once tends to stick even as the incident evolves. The classic misuse is setting the severity after the fact to match the response already given, so the record justifies the reaction. The discipline that guards against this is to fix thresholds in advance, declare on the worst plausible reading and re-grade as evidence arrives, and audit grades in the review afterward.^[1]

How it implements the components¶

Severity Matrix Activation fills the classify-and-trigger front end of the archetype — only the components a classifier can produce:

incident_trigger_condition — the bright line on the grid; crossing it is what declares an incident exists at all.
severity_and_priority_classifier — the grid itself, mapping observed signals onto a discrete severity grade.
acute_phase_boundary — declaring a qualifying grade opens the acute phase; dropping below it is one of the signals to close it.

It does not order the individual work items inside the incident — that is Triage & Prioritization Protocol — nor stand up the commander and decision authority the grade calls for, which is the Incident Command System.

Instantiates: Acute Stabilization Command — Severity Matrix Activation is usually the first mechanism to fire; its grade configures the rest of the regime.
Sibling mechanisms: Triage & Prioritization Protocol · Incident Command System · Common Operating Picture Board · Containment or Rollback Action · Deactivation Checklist · Incident Action Log · Incident Response Runbook · On-Call Rotation Activation · Post-Incident Review (Hotwash) · Reversible Service Degradation · Root-Cause Analysis Handoff · Status Update Cadence · War Room / Incident Channel

Notes¶

Severity is not priority. This mechanism sets the response tier for the whole incident — how much machinery to switch on; it does not decide which task inside the incident gets worked first, which is triage. Conflating the two leads teams to treat a SEV1 as a to-do list rather than a resourcing level, or to re-open the severity debate every time a single task's urgency shifts.

References¶

[1] Discrete severity levels (commonly written SEV1 for the most severe down through SEV4/SEV5) are a widely used operations convention for exactly this purpose — a shared, pre-agreed scale so that "how bad is it" resolves to the same grade regardless of who is on call. ↩