A fault tree is an argument dressed as arithmetic. Somewhere above the gates sits a claim — this hazard is improbable enough — and the tree exists to make that claim inspectable. Most engineers are taught to build trees. Assessors, certification authorities, and independent reviewers are taught to read them, and they read differently: not "does the number at the top look reasonable" but "if this tree were going to mislead me, where would it do it?"
That reading skill is worth stealing. Put your own programme's trees through an auditor's questions and the weaknesses surface years before a review finds them. Here is the walk, in the order an experienced reader takes it.
Start at the top, and stay literal
The first questions are about the top event, because every branch below inherits its meaning. What undesired state, of what system, in which operating phase, over what exposure interval? "Loss of braking" is not a top event; "undetected loss of braking during the landing roll" is. That precision is load-bearing: a fuzzy top event makes the quantification unfalsifiable, because nobody can say which failures belong under it and which do not.
Then the auditor holds the top event against the hazard it claims to serve. The functional hazard assessment declared the hazard and set the probability target; the tree exists to demonstrate the design meets it. If the top event's wording, mission phase, or exposure time has drifted from the hazard log's, the tree may be proving something adjacent to — and easier than — the claim the safety case rests on.
Gates encode beliefs, not just logic
The second reading is of the gates, and it rests on a fact the symbols hide: every gate is a claim about the world, not just a Boolean operator.
An OR gate claims completeness — these are all the ways this event happens. That claim is only checkable against something outside the tree, which is why an auditor reads OR gates with the FMECA open: the failure modes recorded for the items in scope should account for the branches, and a mode in the FMECA with no home in the tree is a finding. OR gates are rarely wrong about the branches they list; they are wrong about the ones they omit.
An AND gate claims independence — these failures do not travel together. This is the strongest assertion a tree can make, because an AND gate multiplies small probabilities together, shrinking that branch's contribution to the top event — sometimes by orders of magnitude. The auditor's reflex is to treat each AND gate as a debt: somewhere, someone owes evidence that the two branches genuinely fail separately.
Hunt the common cause
Which brings the reading to its most productive stop: the common-cause hunt. Redundant channels share more than their designers intend — a power supply, a cooling path, a vibration environment, a maintenance procedure, a manufacturing batch, a software load, sometimes the same technician on the same shift. Any of these can fail both branches of an AND gate together, and the moment one does, the multiplication that made the top event acceptably improbable was fiction.
Common-cause failure modelling exists as a discipline for exactly this reason. The auditor's move is mechanical and merciless: for every AND gate, ask what single event sits beneath both branches. If the honest answer is "the same connector, torqued by the same procedure", the tree flatters the design, and the number at the top is telling a story the hardware will not honour.
Every number has a provenance, or it has nothing
Below the logic sit the basic events, and with them the quantification. Here the auditor stops reading structure and starts reading pedigree.
Where does each failure rate come from — a handbook prediction, fleet data, a supplier's claim, engineering judgement? All four are legitimate so long as the record says which one it was. An auditor who asks "why is this event 2×10⁻⁶ per hour" is really asking to see the record — and "it was in last year's tree" is the answer that ends reviews badly.
The units deserve equal suspicion. Per-hour and per-demand rates mixed in one tree; mission times inconsistent between branches; latent failures quantified without their inspection interval. The last is the quiet one: an undetected failure accumulates probability between tests, and a tree that ignores the test interval understates it. All of them are plain errors, and all of them are invisible at the top of the tree.
Finally, the cut sets. The minimal cut sets are the tree's own confession of what actually drives the top event, and the dominant ones should make physical sense to an engineer who knows the system. A top-event number dominated by one implausible cut set is an arithmetic artefact asking to be investigated.
The tree does not live alone
When a fault tree contradicts its sibling analyses, one of them is wrong — even if every gate in the tree is sound. So the auditor cross-reads: severity-critical failure modes from the FMECA should appear in the relevant trees; the rates on basic events should match the current revision of the prediction, not March's; the target at the top should still be the one the hazard log carries. Each mismatch is a small finding; a pattern of them is the real one — the artefacts are being maintained separately, and the safety case is a collage.
The deepest version of this question is about time. Trees are typically rebuilt for reviews and age in between, while the design moves: a part substitution, a supplier change, a new thermal analysis. The method itself — codified in IEC 61025 — even says the tree should evolve with the design; what it cannot supply is the mechanism, because keeping a tree current is not a logic problem. It is a data-management problem, and it is where trees quietly fail their next audit.
How RAMSynapse approaches this
Almost every question in this article is a provenance query: where did this number come from, is it current, does it agree with the analysis next door. We built RAMSynapse so those questions have machine answers. Basic events reference the same live registry the predictions compute into and the FMECA reads from, every value carries its source, and when a rate changes upstream — a BOM substitution, a revised stress, fresh field data — the affected trees re-quantify and flag what moved. The cross-checks an assessor performs by sampling become properties the platform maintains continuously.
The auditor's questions do not change. What changes is how the programme feels when they are asked — archaeology, or a lookup.
Read your next tree this way: top event literally, gates as claims, AND gates as debts, numbers as records, siblings as witnesses. Trees will tell you where they are weak. They always do.
Want to put an auditor's questions to a live fault tree? Request a walkthrough.