Skip to content
All tools
OperationsIntermediate

Fault Tree Analysis

Work backward from an unwanted top event through the combinations of failures that could cause it.

In one minute

Work backward from an unwanted top event through the combinations of failures that could cause it.

Define one top event, decompose necessary and sufficient causal paths with AND and OR gates, identify shared causes and minimum combinations, then verify against system evidence. Probabilities require justified data and independence assumptions.

The problem it addresses

A team lists hazards but cannot see which common causes or combinations defeat several safeguards at once.

An orbital habitat risks losing breathable air. Two nominally independent scrubbers share a power bus, while manual fallback depends on the same alarm.

When to use it

  • Use Fault Tree Analysis when a team lists hazards but cannot see which common causes or combinations defeat several safeguards at once.
  • The team can examine: A bounded top event, system architecture, failure evidence, safeguard design and relevant domain expertise.
  • A relevant situation is: An orbital habitat risks losing breathable air. Two nominally independent scrubbers share a power bus, while manual fallback depends on the same alarm.

When not to use it

Do not use it to replace evidence, accountable judgement or affected people's participation.

Drawing only component failures while ignoring shared power, human response and unknown modes; inventing precise probabilities.

Inputs required

A bounded top event, system architecture, failure evidence, safeguard design and relevant domain expertise.

Step-by-step process

1. Bound the decision and name its owner.

Write the scope, decision owner and people who can veto or revise the result before starting the workshop.

2. Collect the necessary evidence and affected perspectives.

Collect and date the necessary evidence: A bounded top event, system architecture, failure evidence, safeguard design and relevant domain expertise.

3. Define the top event and system boundary precisely.

Record the evidence and decision criterion for: Define the top event and system boundary precisely.

4. List immediate causes and connect them with justified AND or OR logic.

Record the evidence and decision criterion for: List immediate causes and connect them with justified AND or OR logic.

5. Decompose branches until basic events can be observed or tested.

Record the evidence and decision criterion for: Decompose branches until basic events can be observed or tested.

6. Check shared dependencies, missing branches and minimal cut sets with experts.

Record the evidence and decision criterion for: Check shared dependencies, missing branches and minimal cut sets with experts.

7. Choose controls and validate the tree against incident and test evidence.

Record the evidence and decision criterion for: Choose controls and validate the tree against incident and test evidence.

8. Record the output, next test and review trigger.

Store the artifact with its evidence links, owner, bounded next test and date or trigger for review.

AI automation lens

AI may sort authorised notes and expose missing evidence. It must not invent observations, silently decide for affected people or present a generated map as validated.

Visual model

Text alternative: Define the top event and system boundary precisely; List immediate causes and connect them with justified AND or OR logic; Decompose branches until basic events can be observed or tested; Check shared dependencies, missing branches and minimal cut sets with experts; Choose controls and validate the tree against incident and test evidence.

Interactive example

Scenario: An orbital habitat risks losing breathable air. Two nominally independent scrubbers share a power bus, while manual fallback depends on the same alarm.

Worked answer: Map air-loss as the top event, expose the shared bus and alarm as common causes, then test independent power and detection paths.

Facilitation notes

Record disagreements before synthesising; ask whose evidence is missing; state who may revise the result.

Expected output

  • An inspectable decision artifact, its assumptions and evidence, a responsible owner, a bounded next test and a review date.
  • Choose controls and validate the tree against incident and test evidence.
  • A named owner, test and review date.

Common mistakes

Drawing only component failures while ignoring shared power, human response and unknown modes; inventing precise probabilities.

Quality checklist

  • The decision and system boundary are explicit.
  • Affected people and alternative accounts are included.
  • Each important claim has a source or is marked as an assumption.
  • An owner, safeguard and disconfirming signal are named.

Template

Open the working template.

Knowledge check

Question: What mistake would undermine this method in the scenario?

Answer: Drawing only component failures while ignoring shared power, human response and unknown modes; inventing precise probabilities.

References

  1. Fault Tree Analysis — method source (opens in a new tab). Accessed 2026-10-09.
  2. Further practice reference (opens in a new tab). Accessed 2026-10-09.

Method profile

The method structures a discussion and a test; it does not establish causal proof or guarantee success.