risk-nexus/docs/method/severity.md

---
id: RISK-METHOD-SEVERITY
type: method
title: "Severity: how bad, how likely, and what is not a risk at all"
status: adopted
owner: risk-nexus
adopted: "2026-08-19"
workplan: RISK-WP-0001-T01
review_interval: 6m
disclosure: public
revision: "adopted-1"
last_reviewed: "2026-08-20"
---

# Severity

This is `risk-nexus`'s judgement instrument. It is not canon, it is not a
standard, and it binds nobody else. It exists so that two findings graded a
month apart are graded the same way, and so that a grade can be argued with.

It was written against three real findings (`RISK-F-0001`, `RISK-F-0002`,
`RISK-F-0003`) and it must keep grading those three sensibly or it is wrong.

## The two axes

### Impact — what happens if it goes wrong once

| Band | Name | Test |
| --- | --- | --- |
| `I1` | negligible | Confined to one component. No data leaves it, no record is falsified, no recovery is lost. |
| `I2` | limited | One system's data or availability. Recoverable. Confined to a single tenant, actor or lane. |
| `I3` | serious | Crosses a boundary — tenant, system, or trust — or removes recoverability for one system. |
| `I4` | severe | Crosses the estate. What is compromised here propagates to everything that trusts it, or the data loss is unbounded. |

Impact is scored at **one occurrence**, not at the worst imaginable campaign.
"An attacker who already owns the cluster could do this too" is not an impact
argument.

### Likelihood — how far anyone has to reach

| Band | Name | Test |
| --- | --- | --- |
| `L1` | remote | Requires access nobody currently holds and no ordinary process grants. |
| `L2` | possible | Requires a foothold the estate does grant somewhere — an in-cluster workload, an agent session, a scoped token. |
| `L3` | likely | Reachable from inside the normal working set with no additional step. |
| `L4` | present | No barrier at all, or it is already happening. |

Likelihood is about **reach**, not about intent or about whether anyone has
bothered. `risk-nexus` does not model attackers; it models what the system
permits.

Where the reporter has not established exposure, the finding says so and the
grade uses the band the *stated* facts support — not the worst case, and not
zero. `RISK-F-0001` explicitly declines to assume a default-deny NetworkPolicy
exists; the grade must decline with it, and the unverified fact becomes a
review item rather than a silent assumption in either direction.

## The grid

|  | `L1` | `L2` | `L3` | `L4` |
| --- | --- | --- | --- | --- |
| `I4` | medium | high | **critical** | **critical** |
| `I3` | low | medium | high | **critical** |
| `I2` | low | low | medium | high |
| `I1` | note | low | low | medium |

Four severities: `low`, `medium`, `high`, `critical`. `note` is not a
severity; see the floor.

## The fidelity modifier

**A control that lies is one impact band worse than the same control absent.**

Apply `+1` impact band (capped at `I4`) when the failure mode produces a
*false record* rather than *no record*: an attestation that a check passed
when nothing checked, an audit line asserting an authorization that was never
made, a green signal derived from an unreachable test.

The reasoning is `RISK-F-0002`'s and the register adopts it: an absent control
is a gap you can find by looking; a lying control is a gap that survives
looking, because the evidence you would look at is the thing that is wrong.
Only one of the two states misleads the person investigating afterwards.

The modifier applies to the state being scored. A finding that describes both
states — control absent today, control lying if switched on in the wrong order —
gets **two scores and one of them is the register's headline**; see
"Which state is scored".

## Which state is scored

The headline `severity` is the state of the world **today**. A hazard that
would be created by a *future* action is not the headline, because a register
that scores hypotheticals stops describing the estate.

The hazard is not lost. It is recorded on the finding as a named
**constraint** with its own grade, and it attaches to whatever action would
trigger it — usually another finding's remediation. `RISK-F-0002` is the
worked example: the gate being off is today (headline), the gate being
switched on while the oracle is forgeable is a constraint on `RISK-F-0001`'s
fix, graded separately and higher.

If the constraint's grade is higher than the headline, the finding says so in
its ruling. A reader must not be able to come away with the low number and
miss the high one.

## Build mode

Every finding is graded twice:

- `severity` — today, in build mode, with today's likelihood.
- `severity_at_production` — the same impact, with likelihood re-read for a
  system carrying real users and real tenant data.

Build mode legitimately lowers **both** axes, for different reasons:
likelihood, where the reach itself depends on a production deployment that has
not happened; and impact, where the data that would be exposed does not exist
yet. What it must never lower is `severity_at_production` — the defect does
not improve because the calendar has not reached it.

> *Amended 2026-08-19 (`RISK-WP-0001-T07`).* This paragraph originally said
> build mode was a likelihood input and never an impact one. Grading the
> unverified tenant boundary broke that: what build mode changes there is the
> consequence of an occurrence, not the reach of it. The instrument was wrong
> on first hard use and is corrected rather than worked around.

Where the two grades differ, the production transition is a mandatory
re-score. `docs/method/review.md` binds the review date to it, so the re-score
is a scheduled event and not somebody's memory.

## Non-adversarial findings

Likelihood is written as reach because most findings are about someone getting
somewhere. Where a finding is about loss, corruption or outage — no backup, no
recovery path, an eviction-prone deployment — there is no attacker to model.

For those, likelihood reads as **the chance of the triggering event inside one
review interval**: `L1` would be surprising, `L2` is an ordinary failure the
estate has seen before, `L3` is expected in the normal course of running,
`L4` is already happening. Impact is unchanged: what is lost, and whether it
comes back.

> *Added 2026-08-19 (`RISK-WP-0001-T07`).* Forced by `RISK-F-0006`, where the
> defect is an absent backup and the reach reading produced nonsense.

## The floor

`INTENT.md`: if a finding would not change anyone's decision, it is a note,
not a risk. Concretely, a register entry requires **both**:

1. **An owner who could act.** Some repo, or the operator, can do something
   about it. No actor, no entry.
2. **A decision that changes.** Recording it alters what someone does, when
   they do it, or what they must not do first.

Fails either test → it is a note in `notes/`, not a finding in `findings/`.
Notes are not graded, not reviewed, and not published. They exist so that
"we saw it" survives without inflating the register.

An `I1`/`L1` cell is `note` in the grid for the same reason: something that
is both negligible and unreachable is a thing we know, not a risk we carry.

Two things the floor does **not** exclude:

- **Known and deliberate.** `RISK-F-0002` is a decision somebody made on
  purpose. It still passes the floor, because it changes what may be switched
  on and in what order. Deliberate is not the same as tracked.
- **Omission-shaped.** `RISK-F-0003` is a default that silently produces
  ungoverned lanes. The individual lane is small; the default is not.

## Provenance is a grading input

All four defects known to this register were found by repos reading their own
code against a ladder, within days of each other. None was found by monitoring.

Where a finding's provenance is "we happened to look", the register does not
get to assume that similar defects would have been caught. That raises
likelihood for the class, not for the instance, and it belongs in the ruling's
reasoning rather than in a modifier — the register grades what is filed, and
notes when the filing was luck.

## Recording a grade

The finding's front-matter carries:

```yaml
severity: critical              # headline, today
severity_at_production: critical
impact: I4                      # band, before modifiers
likelihood: L3
fidelity_modifier: false        # true if +1 applied, with the reason in the ruling
```

and the ruling section states impact, likelihood, any modifier, and the one
sentence that would have to become false for the grade to change.