Failure Tree Analysis¶
Reliability model — instantiates Causal Mechanism Mapping
Traces an undesired top event down through the combinations of component failures and enabling conditions that can produce it.
Failure Tree Analysis works the causal question backwards and combinationally. It starts from a single undesired top event — the failure you must never see — and decomposes it downward through logic gates into the combinations of lower-level faults and conditions that could produce it. Its defining move is Boolean: an AND gate says a branch fires only if all its inputs occur (two independent safeguards must both fail), while an OR gate says any input suffices. That structure captures what a forward one-way pathway cannot — that a catastrophe usually needs several things to go wrong together, and that identifying the smallest such combinations (the "cut sets") tells you exactly which shared conditions or single points would defeat multiple defenses at once. It is the tool for when the target effect is a failure state guarded by redundant barriers.
Example¶
An airline reliability team analyzes the top event "total loss of flight-control hydraulic pressure" on a wide-body jet — an event whose probability must be shown to be extraordinarily small. They build the tree downward. Under the top event sits an AND gate: the aircraft has three independent hydraulic systems, so total loss requires all three to fail. Each system's branch then expands under OR gates into its own failure causes — pump failure, a line rupture, fluid loss, a reservoir leak.
The tree's payoff is the cut sets — the minimal combinations that produce the top event. Three unrelated pump failures at once is a valid but astronomically unlikely cut set. But the analysis surfaces a far more dangerous one: a single condition that fails all three systems together — the three hydraulic lines routed through one section of the tail, where one uncontained engine-disk fragment could sever them simultaneously. That is a boundary condition (the shared routing) that collapses the "three independent systems" defense into effectively one, and it names a responsibility boundary — the design and routing owner — where the fix lives. The tree turns a vague "how could we lose all hydraulics?" into a ranked list of exactly which combinations, and which shared conditions, deserve engineering attention.
How it works¶
- Fix the top event precisely. The undesired outcome is stated as one specific, observable failure state; the entire tree hangs from it, so vagueness here poisons everything below.
- Decompose through logic gates. Each level asks "what combination immediately below would cause this?" — AND for faults that must co-occur, OR for any-of alternatives — until reaching basic events that are not decomposed further.
- Find the minimal cut sets. Reduce the tree to the smallest combinations of basic events that alone produce the top event; a single-element cut set is a single point of failure and a red flag.
- Hunt shared conditions across branches. The highest-value insight is a common enabling condition that appears in several branches at once, because it silently converts independent-looking defenses into a correlated failure — and it names who owns the fix.
Tuning parameters¶
- Decomposition depth — how far down basic events are expanded. Deeper trees find subtler cut sets but explode in size and demand failure data the analysis may not have.
- Basic-event resolution — how finely a "component failure" is split. Finer resolution catches shared parts and conditions; coarser keeps the tree tractable but can hide a common cause.
- Common-cause modeling — whether correlated failures (shared power, shared routing, shared maintenance crew) are explicitly represented. Ignoring them is the single biggest source of over-optimistic reliability estimates.
- Quantification — whether gates carry failure probabilities or stay purely logical. Numbers enable a top-event likelihood but invite false precision when the input rates are guesses.
- Scope boundary — how much of the surrounding system and human/organizational factors the tree admits. Wider scope catches procedural and maintenance causes; narrower keeps it an equipment model.
When it helps, and when it misleads¶
Its strength is reasoning about combinations and redundancy: it is the right tool whenever a failure requires several conditions to align, or whenever a system relies on layered defenses whose independence must be verified. Its cut-set analysis is uniquely good at exposing the single shared condition that defeats multiple barriers — the failure mode intuition consistently misses.
Its failure mode is the independence illusion: the tree's math multiplies branch probabilities as if failures were unrelated, so it computes a reassuringly tiny top-event likelihood while a common cause quietly links branches the tree drew as separate — the classic pattern behind disasters where "independent" safeguards all failed for one shared reason.[n1] The classic misuse is trusting the top-event number without auditing whether the cut sets are truly independent, or omitting human and organizational conditions so the tree models only the hardware. The guarding discipline is to treat every multi-branch cut set with suspicion for hidden shared conditions, model common-cause failures explicitly, and read the tree as a structure of combinations to be hardened rather than a probability to be quoted.
How it implements the components¶
Failure Tree Analysis fills the combinational failure-state components — the ones a backward fault model carries:
candidate_cause— the basic events at the leaves are the candidate contributing faults, entered as combinations rather than a single named cause.target_effect— the top event is the target effect, specified as a precise undesired failure state the whole tree decomposes.boundary_condition— shared enabling conditions (common power, routing, environment) that must be present for a branch to fire are made explicit, and their presence across branches is the tree's key finding.responsibility_boundary— each cut set localizes which subsystem, owner, or control gap is accountable for a defense, turning failure structure into assignable prevention.
It does not trace a forward one-way mechanism_chain — that is Mechanism Map — nor does it manipulate anything to confirm the pathway: intervention_point and causal_test belong to Intervention Test. The tree reasons backward from an effect through combinations, and stops at structure rather than experiment.
Related¶
- Instantiates: Causal Mechanism Mapping — specializes the archetype for failure states with multiple enabling conditions, reasoning from effect back to fault combinations.
- Sibling mechanisms: Mechanism Map · Causal Diagram · Causal-Loop Map · Intervention Test · Causal Inference Review · Contribution Analysis · Theory of Change Model · Process Tracing · Root-Cause Analysis
Editorial Notes¶
Form Classification¶
Form family: Analysis, Modeling & Optimization
Rationale: Failure Tree Analysis operates as a computation, comparison, model, or analytic representation used to infer, estimate, or choose because it traces an undesired top event down through the combinations of component failures and enabling conditions that can produce it.
Independent corroboration: The frozen evidence defines Failure Tree Analysis as 'Traces an undesired top event down through the combinations of component failures and enabling conditions that can produce it', so its operative form is Analysis, Modeling & Optimization.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Fault-tree analysis is a canonical safety and reliability engineering model decomposing top events through logical combinations of failures.
Related originating lineages:
- Military & Strategic Studies — Aerospace and defense safety programs materially drove early formal development and deployment.
Review resolution: Both reviewers agree that engineering_design is primary. I retain military_strategic_studies only as formative origin lineages; single_lineage is appropriate because the alternate domains informed practice without constituting independent ownership. Reach is specialized because the mechanism remains tied to a bounded professional technique, an applicability judgment kept separate from provenance. Encyclopedia synthesis is false because the artifact is already established enough that encyclopedia-specific synthesis is not required. The reviewers' stated ambiguity is retained verbatim in the final record.
Attribution caveat: The file title uses failure tree, while the established professional term is fault-tree analysis.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Failure Tree Analysis reasons in the opposite direction from most siblings: it starts at the effect and works down to causes, and it is combinational rather than sequential. That backward, any-combination structure is why it belongs in safety and reliability work — where the question is not "what does this cause?" but "what combination could cause this, and which shared condition would defeat our defenses?"
[n1] A common-cause failure is a single event or condition that fails multiple ostensibly independent components at once, invalidating the independence assumption that makes redundant systems reliable. Failure tree analysis is only trustworthy when such shared conditions are modeled explicitly; overlooking them is the recurring root of "impossible" simultaneous-safeguard failures. ↩