Risk Classes

"A health check and an OS upgrade are not the same risk. Gating them the same is either paranoia or negligence — and you don't get to pick which."

Not every action earns the same ceremony

If every action needs an approval, people rubber-stamp — approval fatigue makes the gate meaningless. If no action needs one, the dangerous ones slip through alongside the harmless ones. Uniform gating fails in both directions. The fix is to make the ceremony proportional to the blast radius, which means sorting actions by risk.

The five classes

Every action lands in one of five: Read (inventory, health probe, diff — no mutation, runs freely with bounded concurrency); Low (refresh known metadata, download without installing — explicit target, little ceremony); Medium (enroll / suspend / retire / restore a host, restart a known service, apply a named sync domain — preview plus approval); High (purge history, migrate the control plane, OS upgrade, reboot, security settings — a typed campaign with explicit approval); and Interactive (the terminal — explicit target, visible identity, human-driven).

Proportional gating

The class decides how much friction an action carries. A read flows; a medium change pauses for a preview and a yes; a high-risk change becomes a whole campaign with its own approval and recovery. The amount of gating tracks the danger, so the approvals you actually see are the ones that deserve a second look — and you never train yourself to click through them.

Interactive is a class, not a loophole

Notice the terminal has its own class. That's deliberate: by making Interactive a named risk category, the system refuses to let raw shell masquerade as one of the safe, previewed kinds. The escape hatch is accounted for, sitting openly in the risk model — not hiding inside a button labeled something calmer.

Match the ceremony to the blast radius. Approve-everything and approve-nothing are the same failure wearing different masks; risk classes are how you escape both.

Code

The class decides the posture·python

RISK = {
    "read":        "no mutation; bounded concurrency; run freely",
    "low":         "explicit target; minimal ceremony",
    "medium":      "preview + approval (enroll/retire, restart service, sync domain)",
    "high":        "typed campaign + explicit approval (purge, migrate, OS upgrade, reboot)",
    "interactive": "the terminal: explicit target, visible identity, human-driven",
}

# The gate you feel is proportional to the damage you could do.
# 'read' never nags; 'high' is never a single unguarded click.
# No arbitrary shell string is ever one of the automated classes --
# it exists only as 'interactive'.

Exercise

List five things you do to your machines, from 'check free disk' to 'reinstall the OS.' Sort them into the five risk classes. Then pick the one you're currently gating too heavily (a read you confirm every time) and the one you're gating too lightly (a destructive action that's one unguarded click) — and swap their ceremony to match their risk.

Hint

The tell for 'too heavy' is any confirmation you always click yes on without reading. The tell for 'too light' is any single button that could ruin your week. Proportional gating means those two feelings should be swapped.

Not every action earns the same ceremony

The five classes

Proportional gating

Interactive is a class, not a loophole

Code

External links

Exercise

Progress

Comments 0