Risk Register¶

Tracking register — instantiates Uncertainty Explicitness

A living table of what could go wrong — each adverse event tagged with its likelihood, its impact, an owner, and the trigger that fires its response — so downside uncertainty stays visible and assigned instead of remembered by whoever happened to worry about it.

A Risk Register is the archetype's instrument for downside uncertainty specifically. It turns each adverse event that might occur into a row that carries not just a description but a likelihood, an impact, a named owner, a planned response, and — the load-bearing part — the condition that would trigger that response. Its distinguishing move among its siblings is ownership and action-routing: where a confidence interval or an error bar represents how uncertain an estimate is, the register assigns each uncertainty to a person and a pre-agreed response, so a known-but-unmanaged risk can never quietly become an unowned one. It tracks events that could hurt the work, not the confidence of a measurement.

Example¶

A team boring a rail tunnel keeps a risk register. One row reads "unexpected groundwater ingress in the eastern segment": likelihood medium, impact high (weeks of delay plus pumping cost), owner the geotechnical lead, trigger "inflow exceeds a set rate at any working face," response "switch to the pre-priced grouting subcontractor." Months later a face starts weeping, the measured inflow crosses the threshold, and the trigger fires. The owner already knows the plan and the pre-negotiated contract already exists. The register did not prevent the water — it made sure the uncertainty had been named, sized, owned, and pre-answered, so the response was a decision taken calmly in advance rather than a scramble at the face.

How it works¶

Each entry names a source of adverse uncertainty and pairs it with a response threshold and an accountable owner. Four things separate a register from a to-do list: rows are uncertainties, not tasks, so many will never happen; each carries a trigger condition — the decision threshold at which its planned response fires; each has an owner and an escalation path for when the risk exceeds that owner's authority; and the whole table is re-scored on a cadence so retired risks leave and fresh ones enter. A risk with no measurable trigger and no owner is not a register entry, it is a worry.

Tuning parameters¶

Granularity — one row per broad theme versus many fine-grained rows. Fine rows catch specific triggers but bloat the register until nobody reads it.
Likelihood/impact scale — qualitative (high/medium/low) versus quantified scores. Quantification sorts risks cleanly but invites false precision on events nobody can truly price.
Trigger specificity — a vague "if things get bad" versus a measurable threshold; the measurable trigger is what turns the register from a worry-list into an action system.
Review cadence — how often rows are re-scored and pruned. Too rare and it rots; too frequent and it becomes theatre.
Escalation ceiling — the impact level above which a risk must leave the team and go to a sponsor.

When it helps, and when it misleads¶

Its strength is memory and accountability: nothing that has been named, owned, and given a trigger can be quietly forgotten. Its failure modes are equally real. It captures only the risks someone thought to write down — the known unknowns — and can lend false comfort against the ones nobody imagined. It decays into a compliance artifact groomed for audits rather than decisions. And its likelihood/impact scores are easily run backwards — scored to justify a go decision already made rather than to test one; coarse qualitative matrices can even mis-rank risks so that a "medium" hides a genuinely worse case than a "high."^[1] The discipline that guards against this is the trigger and the review: an entry with no measurable trigger and no owner is decoration, and each review must delete stale rows as aggressively as it adds new ones.

How it implements the components¶

uncertainty_source_inventory — each row names a distinct source of adverse uncertainty (a hazard, a fragile dependency, an exposed interface), so the register doubles as an inventory of where the work can be surprised.
decision_threshold_link — the trigger condition on each row is a decision threshold: it states exactly what state of the world fires the planned response.
escalation_or_review_rule — the owner and the escalation ceiling route each risk to the right authority and back into periodic re-review.

It does not represent the confidence of an estimate (confidence_representation, precision_discipline) — that is Confidence Interval and Confidence Label — nor does it log the premises a plan is betting on (assumption_log), which is the Assumption Register's job.

Instantiates: Uncertainty Explicitness — the register makes downside uncertainty inspectable, owned, and pre-answered.
Sibling mechanisms: Known Unknowns Log · Assumption Register · Caveated Decision Memo · Confidence Interval · Confidence Label · Error Bar · Evidence Grade Rubric · Forecast Range · Model Limitations Card · Probability Estimate · Uncertainty Band

Notes¶

The register handles risks — events that might happen and hurt. Keep it distinct from the Known Unknowns Log (open questions you do not yet have an answer to) and the Assumption Register (premises you are currently betting on). Collapsing the three into one table is the classic failure: a bet you are making is an assumption, an unanswered question is an unknown, and a possible bad event is a risk — and each wants a different response.

References¶

[1] The "risk matrix" that pairs a coarse likelihood band with a coarse impact band is a standard register scoring device, but its coarse categories can rank risks in an order that does not match their true expected loss — a well-documented limitation that is why quantified or trigger-based scoring is preferred where the stakes justify it. ↩