Opportunity Exposure Register¶

Exposure register — instantiates Eventual-Occurrence Containment Design

Keeps a living inventory of every place the adverse outcome could occur and how fast opportunities are piling up, so the 'many chances' fact never quietly goes stale.

Opportunity Exposure Register is the bookkeeping layer of the whole design: a living inventory of every surface, channel, or activity where the adverse outcome could occur, each line tagged with the unit of opportunity (one request, one flight, one dose, one deploy), the count of those units accumulating over the operating horizon, and the person accountable for it. Its one job the others don't do is keep the denominator honest. The archetype's whole argument — that a per-chance probability treated as "basically zero" becomes near-certain across enough chances — only bites if someone is actually counting the chances, and counting them as they grow. The register is where that count lives, gets an owner, and trips a refresh when exposure drifts past what the risk model assumed.

Example¶

A payments platform maintains an exposure register for one specific harm: exposing a customer's full card number in the clear. Rather than one vague "data-leak risk," the register enumerates each place a card number can be unencrypted — the tokenization service, the fraud-scoring pipeline, three internal admin tools, a nightly export job — and for each line records the unit of opportunity and its running count: the tokenization service handles ≈40M card reads a month, the export job runs once nightly, and so on. Each line carries a named owner and the date its risk estimate was last refreshed.

Six months in, the fraud pipeline's volume has quietly tripled after a large merchant onboarded. The register's drift trigger flags that this line's monthly exposure now exceeds the band the last assessment assumed and routes it back to its owner for a fresh look. Nobody had to notice by intuition that a rare event had gotten less rare — the register noticed, because keeping the count current is the only thing it is for.

How it works¶

Enumerate exposure surfaces, not risks in the abstract — one line per place the outcome can actually occur.
Fix the unit of opportunity for each line (a request, a cycle, a shipment) and attach a live count over the horizon, sourced from real telemetry wherever possible rather than a one-time guess.
Assign exactly one accountable owner per line — the register refuses anonymous risk.
Set a drift band per line; when the accumulating count crosses it, fire a refresh trigger that sends the line back for reassessment. The register tracks change in exposure — the signal that point-in-time analyses structurally miss.

Tuning parameters¶

Line granularity — one lumped surface versus many fine-grained ones. Finer lines localize drift and ownership but cost upkeep and can bury the big exposures in noise.
Unit choice — what counts as one opportunity (a request? a session? a user-day?). The unit sets the denominator every downstream probability uses; pick the one the harm actually scales with.
Drift-band width — how much exposure growth is tolerated before a refresh fires. Tight bands catch creep early but cry wolf; wide bands stay quiet until the model is badly stale.
Refresh trigger, count vs. calendar — re-examine when exposure crosses a threshold, on a fixed cadence, or both. Count-based catches surges; calendar-based catches slow rot.
Owner resolution — team-level versus named-individual accountability. Named owners act faster but churn; teams are durable but diffuse.

When it helps, and when it misleads¶

Its strength is that it converts "we should keep an eye on this" into a durable, owned artifact whose sole purpose is to keep the exposure count current — so nobody has to remember that a rare event is getting less rare as volume climbs. It is the antidote to the most common failure in this archetype: a risk model that was right at launch and silently wrong a year later because exposure grew tenfold and nothing re-ran.

Its failure modes are those of every register: it rots. An unowned or unaudited register becomes a compliance ornament — complete-looking, months stale, consulted by no one — which is worse than none, because it manufactures false confidence. The classic misuse is maintaining it to satisfy an auditor rather than to drive action, so lines get marked "reviewed" without the count ever being checked against reality. The discipline that keeps it honest is to source counts from live telemetry rather than self-report, and to treat a fired drift trigger as work that must close, not a notification to dismiss. Borrowing the discipline of the risk register^[1] — every entry owned, dated, reviewed — is what separates a live register from a graveyard.

How it implements the components¶

opportunity_unit_and_horizon — each line fixes the unit of opportunity and the horizon over which its count accumulates; this is the register's core content.
exposure_drift_and_model_refresh_trigger — the per-line drift band and the trigger it fires are the mechanism that catches exposure outgrowing its last assessment.
accountable_risk_owner — every line carries a named owner, so each exposure has someone answerable for it.

It computes no probability from these counts — the per-opportunity bound and the cumulative-over-horizon math belong to Repeated-Trial Probability Calculator and Probabilistic Safety Assessment — and it designs no containment, detection, or recovery; those are siblings' work.

Instantiates: Eventual-Occurrence Containment Design — the register supplies the exposure denominator the rest of the design reasons over.
Sibling mechanisms: Repeated-Trial Probability Calculator · Probabilistic Safety Assessment · Cumulative Risk Horizon Table · Fault Tree with Repeated-Opportunity Branch · Sentinel Event Monitoring · Automatic Isolation Trip · Blast-Radius Test · Degraded-Mode Runbook · Failure-Injection Test · Post-Incident Recurrence Review · Recovery Drill and Restore Test · Stop-or-Scale-Back Gate

Notes¶

The register is deliberately only the denominator-keeper: it counts opportunities and flags drift but asserts nothing about how likely or how bad the outcome is. That separation is what lets exposure tracking (which changes weekly) evolve independently of the risk model (re-run only occasionally) — the drift trigger is precisely the handshake between the two.

References¶

[1] A risk register — the standard project- and enterprise-risk artifact listing each identified risk with an owner, likelihood, and review date. This mechanism narrows the idea to one archetype: it registers opportunities for a single adverse outcome and tracks their accumulation, rather than a heterogeneous list of project risks. ↩