There are two directions you can reason about failure, and mature safety programs use both because each catches what the other misses. FMEA, Failure Modes and Effects Analysis, reasons forward: it starts at the components, walks through every way each one can fail, and traces the consequences upward to the system. Fault Tree Analysis reasons backward: it starts at a single undesired outcome, the loss of an aircraft, the inadvertent release of energy, the delivery of the wrong therapeutic dose, and works down through the logical combinations of lower-level failures that could cause it. The forward method is exhaustive but flat; the backward method is focused but reveals structure, and specifically reveals the combinations of failures that no single-component analysis can see.
A fault tree begins with a top event, and choosing it well is half the discipline. The top event is a specific, undesired outcome stated precisely enough to analyze: not failure of the braking system in general but loss of braking capability during a landing rollout, not a software fault but the commanding of full thrust while on the ground. From that top event the analysis works downward, asking at each level what immediate causes could produce the event above, and connecting them through logic gates. An OR gate means any one of the inputs is sufficient to cause the event above it. An AND gate means all of the inputs must occur together. This gate logic is the entire expressive power of the method, and it is enough to capture the essential structure of how failures combine.
The distinction between OR and AND gates is where fault tree analysis earns its place, because it is exactly the distinction that reveals whether a design is robust or brittle. An outcome that sits above an OR gate with many inputs is fragile: any single one of those failures triggers it, and the system has no defense in depth against that outcome. An outcome that sits above an AND gate is protected by redundancy: it requires a coincidence of failures, and the more independent inputs the AND gate has, the less probable the coincidence. Reading a fault tree is largely a matter of finding the OR gates close to the top, the places where a single failure defeats the whole system, and asking whether that exposure is acceptable or whether the architecture needs another independent barrier.
The analytical payoff of the tree is the minimal cut set, and it is the concept that makes the method worth the effort. A cut set is any combination of basic events that together cause the top event; a minimal cut set is one with no unnecessary members, an irreducible way for the system to fail. A minimal cut set of size one is a single point of failure, a lone basic event that on its own produces the catastrophic top event, and finding those is often the first reason a program builds the tree at all. Larger cut sets tell you how many independent things must go wrong together, which is both a qualitative measure of robustness and, when the basic events have failure probabilities, the basis for quantifying the probability of the top event itself.
That quantification is the second reason safety-critical domains reach for fault trees rather than settling for FMEA alone. When each basic event carries a probability, the tree computes the probability of the top event by combining those probabilities through the gate logic, and that number is exactly what the safety standards demand. The catastrophic failure condition budgets in civil aviation, the tolerable hazard rates behind the safety integrity levels of IEC 61508, the probabilistic risk targets in nuclear licensing, all of them require a defensible number for the probability of a defined bad outcome, and a fault tree is the standard way to produce it. FMEA tells you what can fail and how; the fault tree tells you how probable the outcome you care about actually is, given the architecture you built.
The two methods are genuinely complementary rather than competing, and understanding why is what tells a program when to use which. FMEA is inductive and bottom-up: it guarantees you have considered every component, which is exactly what you want for completeness and for catching failure modes nobody would have thought to include in a top-down tree. Fault tree analysis is deductive and top-down: it starts from the outcomes that must not happen and finds the combinations that cause them, which is what you want for revealing multi-failure scenarios and single points of failure that a component-by-component sweep leaves implicit. Many rigorous programs run FMEA to establish the failure modes and then feed those modes into fault trees as basic events, using the inductive method to guarantee coverage and the deductive method to reveal structure and produce numbers.
None of this analytical value survives if the fault tree is a static drawing disconnected from the design it analyzes, and this is where most programs quietly lose the benefit. A fault tree is only true relative to a specific architecture and a specific set of failure modes; change the design, add a redundant path, delete a component, revise a failure rate, and the tree that was accurate yesterday now describes a system that no longer exists. The basic events at the bottom of the tree correspond to real components and functions in the design, and the top event corresponds to a hazard the program is tracking. When those correspondences are maintained only in an analyst memory and a separate drawing tool, the tree ages out of agreement with the design, and a program discovers during an audit that its safety case describes an earlier version of the system.
This is the connection methodology-native tooling is built to keep alive. In Hitt Hosting SE the failure modes, the hazards, and the requirements a fault tree reasons about live as connected elements, so the basic events at the bottom of a tree trace to the real components and functions in the design and the top event traces to the hazard and the safety requirement it threatens. When a design element or a failure mode changes, the analyses that depended on it are flagged for reassessment instead of silently going stale, so the minimal cut sets and the single points of failure a fault tree exposed stay current as the architecture evolves. The safety case a certification authority asks to see becomes a view of the live program, with the fault trees, the FMEA, and the hazards they share all pointing at the same underlying design rather than at three documents that agreed only on the day they were written.