Fault Tree with Repeated-Opportunity Branch¶

Analytical failure-logic model — instantiates Eventual-Occurrence Containment Design

A top-down failure-logic tree with an added branch for the event recurring across many demands — compounding a small per-demand probability into a horizon-level one and exposing where the 'independent trials' assumption quietly breaks.

A fault tree decomposes a top-level failure into the exact combinations of smaller failures that can cause it — AND-gates where several things must fail together, OR-gates where any one will do. Fault Tree with Repeated-Opportunity Branch is that classic model with a deliberate extension: an explicit branch representing the event's repeated chances to occur, so a small per-demand probability is compounded across the many demands the system will actually face, and — just as important — the correlations that make those demands not independent are forced into view. Its distinguishing contribution is the logical structure of failure plus a stress test of the independence assumption on which any repeated-trial number rests. That sets it apart from the table that lays cumulative risk across a horizon, from the empirical test that measures propagation, and from the full assessment program that integrates many such trees; this is one deductive model, aimed at how failures combine and whether the trials really are independent.

Example¶

An offshore drilling operation relies on a blowout preventer (BOP) to seal the well on demand. A fault tree for "BOP fails to seal on demand" branches downward: failure of the shear rams, OR failure of the control pods, OR loss of hydraulic supply, each decomposing further. Any single branch, per demand, carries a small probability of failure on demand (PFD). The repeated-opportunity branch then compounds that PFD across the many activations expected over a well program — and the cumulative chance of at least one failed seal turns out to be far from negligible, even though each demand looked safe in isolation. Then the tree earns its keep a second time: the two "redundant" control pods, drawn as an AND-gate (both must fail for control to be lost), are found to share a single hydraulic supply. That shared root quietly turns the AND into an OR — the independence the redundancy assumed does not hold — and the model flags it as a dependence the simple trial count cannot survive. Tracing how a failure would then physically propagate through the rig is a separate, empirical job; the tree's contribution is exposing that the independence was never real.

How it works¶

The method is deductive: start from the undesired top event and work downward into the boolean combinations of basic events that produce it, rather than forward from causes. Onto that structure it adds two things the plain tree omits. First, the repeated-opportunity branch, which takes the per-demand probability and compounds it over the demand count so the horizon-level chance is visible, not buried. Second, an explicit independence audit of the basic events — are they truly independent, or are they clustered, shared-cause, or driven by an adversary who adapts across attempts? The tree is where you discover that two barriers drawn as independent actually share a power supply, a calibration, or a maintenance crew, and that the reassuring AND-gate is really an OR.

Tuning parameters¶

Decomposition depth — how far down toward basic events to resolve each branch. Deeper trees expose hidden shared roots but cost effort and can sprawl; shallow trees are fast but hide couplings.
Basic-event probability sourcing — measured field data versus expert judgment for each leaf. Soft inputs dominate the result, so where the numbers come from matters more than the gate logic above them.
Dependence / common-cause modeling — how correlated failures are represented (for example, a beta-factor for shared-cause). This is the highest-leverage and most-abused dial: assume independence and the number flatters; model the shared cause and redundancy can collapse.
Repeated-opportunity count — the demand horizon over which the per-demand probability is compounded. Choosing it honestly is what makes the branch meaningful rather than decorative.
Adversarial branch — whether to model an attacker who makes many attempts and adapts after observing defenses, rather than a fixed stochastic demand.

When it helps, and when it misleads¶

Its strength is showing the AND-gate that is really an OR — the "independent" barriers that share a root — and compounding a per-demand risk over the true number of demands instead of judging one demand at a time. Its failure modes are the archetype's sharpest. False independence is the most serious technical error: assuming redundancy that shares a cause, so the model reports a reassuring product of tiny probabilities for an event that is really one shared failure away. The tree is also easily built backwards — basic-event probabilities and gate choices tuned until the top number clears a required threshold, manufacturing compliance rather than testing it. And any fault tree suffers the completeness illusion: it contains only the failure modes someone thought to draw. The discipline is to hunt common-cause explicitly^[1], source basic-event probabilities honestly, and treat the tree as a structured argument whose assumptions must hold — not a proof of safety.

How it implements the components¶

Fault Tree with Repeated-Opportunity Branch realizes the failure-logic and independence slice of the archetype's model inputs — the parts a deductive model derives and stress-tests:

per_opportunity_probability_bound — by combining basic-event probabilities up through the gates, it derives the per-demand probability of the top event that the rest of the analysis rests on.
dependence_and_mixing_assumption_check — its core discipline is testing whether the demands and barriers are truly independent, or clustered, shared-cause, or adaptive, before any trial count is trusted.
adversarial_attempt_model — the branch that models an adversary making repeated, adapting attempts rather than a fixed stochastic demand.

It structures how failures combine and stresses independence but does not lay the result across the operating horizon or mark the posture switch (Cumulative Risk Horizon Table), test how a failure propagates empirically (Blast-Radius Test), or integrate everything into a full risk program (Probabilistic Safety Assessment).

Instantiates: Eventual-Occurrence Containment Design — the tree supplies the per-opportunity probability and the dependence check the archetype requires before treating occurrence as a design basis.
Sibling mechanisms: Cumulative Risk Horizon Table · Probabilistic Safety Assessment · Repeated-Trial Probability Calculator · Blast-Radius Test · Opportunity Exposure Register · Automatic Isolation Trip · Degraded-Mode Runbook · Failure-Injection Test · Sentinel Event Monitoring · Recovery Drill and Restore Test · Post-Incident Recurrence Review · Stop-or-Scale-Back Gate

Notes¶

The repeated-opportunity branch is both the point and the peril. Compounding a per-demand probability over many demands is valid only while the demands stay independent — so the branch and the dependence check have to live in the same model. A repeated-opportunity fault tree that quietly assumes the independence it never tested does not just get the number slightly wrong; it manufactures false confidence precisely at the horizon scale where the archetype says the danger lives.

References¶

[1] A common-cause failure is the simultaneous failure of multiple, nominally redundant components from a single shared cause (a shared power supply, calibration, or environment). It is the standard reason a fault tree's independence assumption fails, and dedicated models (such as the beta-factor) exist to represent it. ↩