Cumulative Risk Horizon Table¶

Decision-support artifact — instantiates Eventual-Occurrence Containment Design

Lays a tiny per-opportunity probability across the real number of opportunities in the horizon, turning 'practically zero' into a cumulative chance — and marking the point where prevention-only must give way to containment.

A one-in-a-million chance looks like zero — until you take a million shots. Cumulative Risk Horizon Table is the artifact that stops a per-opportunity probability from being read as horizon-level safety. It takes the chance of the event on a single opportunity and lays it across the actual count of opportunities the system will see over a relevant window — requests per month, cycles per year, doses per population — and tabulates the cumulative chance of at least one occurrence, scenario by scenario. Its defining feature is the line it draws through that table: a marked posture-switch threshold where cumulative risk becomes large enough that prevention-only reasoning is no longer acceptable and containment becomes required. It is not the calculator that crunches a single number, and not the fault tree that derives the per-opportunity odds; it is the decision layout that makes "when, not if" visible and turns it into a governed trigger.

Example¶

A consumer login endpoint carries a residual per-attempt account-takeover probability of about 1-in-a-million after all preventive controls (rate limits, breached-password checks). That feels negligible per attempt. The table sets it against reality: the endpoint absorbs roughly 2 billion credential-stuffing attempts a year. Rows are horizons — a day, a month, a quarter, a year; columns are probability scenarios — optimistic, base, conservative. Each cell shows the cumulative chance of at least one successful takeover. The base-case column crosses the pre-agreed posture-switch threshold somewhere around month three: cumulative probability is no longer small, and it keeps climbing toward near-certainty over the year. That single crossing reframes the whole security conversation. "Enforce strong passwords" (prevention) is no longer a sufficient answer; below the threshold line, the design must add containment — cap the blast radius of any one compromised account through least privilege, session limits, and anomaly-triggered isolation. The table doesn't argue for that; it makes the argument unavoidable.

How it works¶

The table is organized by horizon: it makes the denominator — the opportunity count — a first-class axis, because a probability without its opportunity count is a half-statement. For independent opportunities it fills each cell with the cumulative-occurrence relation 1 − (1 − p)ⁿ^[1]; for the general case it carries scenario bands instead of a single line, showing how the answer swings with volume growth and with error in the soft probability p. Then it does the one thing a bare calculator does not: it marks the posture-switch row, so the transition from "keep preventing" to "now also contain" is explicit, auditable, and attached to a number rather than to nerve. The arithmetic is trivial; the value is the layout and the line.

Tuning parameters¶

Opportunity unit — per-request, per-session, per-user, per-cycle. The unit sets n, and the wrong unit can shrink or inflate the whole table. Choose the unit that matches how the event actually gets a chance to happen.
Horizon length — day, month, year, program lifetime. This is the most decision-relevant dial and the most abused: a short horizon can keep the cumulative number flattering. Fix it to the decision, not to the answer you want.
Probability scenario band — how wide a range of p to carry. A single point hides the uncertainty; an optimistic-to-conservative band shows how fragile the conclusion is.
Threshold placement — how much cumulative risk trips the posture switch. Lower is more cautious and switches to containment sooner; higher tolerates more residual before acting.
Growth assumption — flat volume versus projected growth. Assuming flat traffic can hide a risk that rising n will deliver next year.

When it helps, and when it misleads¶

Its strength is that it kills per-opportunity myopia and makes the posture switch a matter of record: everyone sees the same cumulative number and the same line. Its failure modes cluster at the two ends of the calculation. Upstream is horizon manipulation — quietly choosing a short window or a narrow opportunity unit so the cumulative number stays below the threshold; the honest guard is to fix the horizon and unit before seeing the result. Downstream is false independence — 1 − (1 − p)ⁿ assumes trials that don't interact, so if opportunities are clustered, correlated, seasonal, or driven by an adaptive adversary, the tidy cell is wrong and must be replaced by a dependence-aware model. And a precise-looking table over a soft p lends false confidence. The discipline is to freeze the framing in advance, carry the dependence caveat on the face of the table, and refresh it when volume grows.

How it implements the components¶

Cumulative Risk Horizon Table realizes the model-input and posture slice of the archetype — the parts a decision artifact assembles and displays:

opportunity_unit_and_horizon — it defines and foregrounds the opportunity unit and the decision horizon as the table's axes, so the denominator is never left implicit.
cumulative_occurrence_model — each cell is the cumulative chance of at least one occurrence over the horizon, computed or scenario-bounded across the grid.
posture_switch_threshold — it marks the row where cumulative risk crosses into "containment now required," turning the switch into an auditable trigger.

It lays out and decides but does not derive the per-opportunity probability or test its independence (Fault Tree with Repeated-Opportunity Branch), crunch the raw numbers (Repeated-Trial Probability Calculator), or enforce the stop the switch implies (Stop-or-Scale-Back Gate).

Instantiates: Eventual-Occurrence Containment Design — the table is where the archetype's central move, the posture switch, is made explicit and defensible.
Consumes: Fault Tree with Repeated-Opportunity Branch and Repeated-Trial Probability Calculator supply the per-opportunity probability and the arithmetic the table arranges.
Sibling mechanisms: Fault Tree with Repeated-Opportunity Branch · Repeated-Trial Probability Calculator · Opportunity Exposure Register · Probabilistic Safety Assessment · Stop-or-Scale-Back Gate · Blast-Radius Test · Automatic Isolation Trip · Degraded-Mode Runbook · Failure-Injection Test · Sentinel Event Monitoring · Recovery Drill and Restore Test · Post-Incident Recurrence Review

Notes¶

The table is a guardrail only while its independence assumption is defensible, and the place it is most often gamed is the choice of horizon and unit — the two dials that set n. Whoever picks those picks the answer. Recording that choice, and the reason for it, before the cumulative number is computed is what separates an honest posture switch from one reverse-engineered to stay below the line.

References¶

[1] For n independent opportunities each with constant probability p, the chance of no occurrence is (1 − p)ⁿ, so the chance of at least one is 1 − (1 − p)ⁿ. When p > 0 this rises toward 1 as n grows — which is why a very small per-opportunity probability can become a near-certainty over a long enough horizon. ↩