# Severity rubric (P0-P4)

The one rule that matters: **never inflate severity, and always justify the call.**
Severity is technical impact ("how badly broken"), not urgency. Priority is the
business call about when to fix it, and a human owns that.

| Code | Name | Definition | Typical example |
|------|------|------------|-----------------|
| P0 | Blocker | System down, data loss, or security breach. No usable workaround. | Login 500s for everyone; payment double-charges; PII leak. |
| P1 | Critical | Major feature broken, no reasonable workaround. | Checkout fails for a whole payment method; cart empties on refresh. |
| P2 | Major | Feature impaired but a workaround exists. | Filter returns wrong order; a form needs a retry to submit. |
| P3 | Minor | Cosmetic issue or minor inconvenience. | Misaligned button; a tooltip that does not dismiss. |
| P4 | Trivial | Enhancement request or typo. | Stale copyright year; a spelling fix. |

Justify every classification against this table. If you are tempted to bump a P2
to P1, write down why the workaround does not count. If you cannot, it is a P2.

## Category (what kind of bug)

`UI` - layout, styling, rendering, copy.
`Functional` - behavior does not match the requirement.
`Performance` - slow, times out, leaks, degrades under load.
`Security` - auth, authorization, injection, data exposure.
`Data` - wrong, missing, or corrupted data; state that persists incorrectly.

## Root-cause layers (where it lives)

Trace the bug down the stack and name the single most likely layer:

`UI -> API -> Service -> DB -> Infra -> Third-party`

- **UI** - the browser/client: rendering, client state, a locator or event.
- **API** - the request/response contract: status, payload, validation.
- **Service** - business logic: a reducer, a calculation, a workflow step.
- **DB** - the data layer: a query, a constraint, a migration, stale rows.
- **Infra** - deploy, config, env, networking, secrets, scaling.
- **Third-party** - an external dependency you do not control.

For each bug, say which layer and which logs or dashboards to check first.

## Confidence

State `high / medium / low` on the severity and root-cause calls. Low confidence is
not a failure, it is honesty: say what evidence (a trace, a repro, a log) would
raise it. A justified "P1, medium confidence, need the checkout logs to confirm the
layer" is more useful than a confident guess.
