Fault tree analysis: start with the worst thing

FMEA works from the bottom up. Every part, every way it could fail, and what happens next. A fault tree works the other way. You start with the one outcome you can't live with, and ask how it could happen.

What it is

Fault tree analysis was developed at Bell Labs in the early 1960s, by H. A. Watson, for the Minuteman missile launch control system. It spread through aerospace, nuclear power and later most safety-critical industries.

The top of the tree is the top event: the thing that must not happen. Below it, you list what could cause it. Below each cause, what could cause that. The branches are joined by gates:

  • OR gate. Any one of these causes is enough.
  • AND gate. All of these have to happen together.

The gates are the point. An OR gate means one failure gets you there. An AND gate means you have layers of protection, and they all have to fail.

Why people skipped it

A good fault tree takes days. Someone has to know the whole system, draw every branch, and keep it consistent. It usually got done only where a regulator demanded it.

How a bot does it

  1. Name one top event. Be specific. "Customer money sent to the wrong account," not "something bad."
  2. Give the bot the system. The process map, the tools and their access, the approval steps, the people.
  3. Have it build the tree. Every cause, every gate, down to basic events you can actually control.
  4. Find the single points. Any path from the top to the bottom made only of OR gates is a single point of failure. Those are what you fix first.
  5. A person checks the gates. Is that really an AND? Do both things really have to fail?

The bot brief

Build a fault tree for this top event: [specific event].
System description: [attached process map, tool list with access, approval steps].
Use only these inputs; mark anything else as GUESS.
Write the tree as an indented outline. Label each gate AND or OR.
Go down until each basic event is something a person could control or check.
Then list every minimal cut set (the smallest set of basic events that alone
causes the top event). Sort them by size, smallest first.
Flag every cut set of size 1 as a SINGLE POINT OF FAILURE.
For each, propose a control that turns the OR into an AND.

Starting point only. Test it on your own data and model, and adjust as needed before you rely on it.

An example

Top event: A bot sends a payment to the wrong account.

TOP: Payment sent to wrong account
└─ OR
   ├─ Bot has a payment tool AND approval is skipped
   │   └─ AND
   │      ├─ Bot has payment tool connected
   │      └─ OR
   │         ├─ Routine runs unattended
   │         └─ Person approves without reading details
   └─ Account details are wrong AND nobody checks them
       └─ AND
          ├─ OR
          │  ├─ Invoice email was fake (phishing)
          │  └─ Bot read old vendor file
          └─ No check against the vendor master

What the tree shows: "Person approves without reading details" sits under an OR. So the approval step, on its own, isn't the strong layer people think it is. Removing the payment tool entirely cuts the whole left branch. See The hierarchy of controls.

Where bots differ

A bot can build a tree with fifty branches without losing track. It can also invent branches that don't exist in your system, or miss a path nobody wrote down. The tree is only as good as the system description you give it.

Fault trees can also carry probabilities. A bot can do the math, but the numbers going in are usually guesses for bot work. Use the structure. Be careful with the numbers.

What this means for you

  • Pick the two or three outcomes you can't accept.
  • Have a bot build a fault tree for each.
  • Look for single points of failure.
  • Add a layer until every path needs two things to go wrong.

Related