A fault tree separates failure logic from probability assumptions

A top event should describe an observable failure under a stated mission or service condition, such as neither of two routes serving an eligible request. An OR gate means any input event suffices; an AND gate means their joint occurrence is required under the modeled conditions. These are logical relationships, not independence claims. A repeated basic event represents the same event wherever it appears. Duplicating its drawing does not create another statistically independent power supply, credential, or deployment action. Boundary conditions and omitted mechanisms should be documented beside the tree.

A cut set is a collection of basic failures sufficient for the top failure. It is minimal when removing any member makes that collection no longer sufficient; minimal does not mean it has fewer members than every other cut set. A tree can have both a one-event minimal cut and a three-event minimal cut. Listing them exposes single points and combinations worth investigating. The list is a consequence of the chosen logic, not proof the model includes every real failure mechanism or every dynamic sequence.

The same basic-event combination can satisfy several cut sets. Adding their probabilities then counts that outcome more than once. Inclusion–exclusion corrects overlap; a rare-event sum can be a useful approximation or upper bound under explicit conditions, but it is not an exact result merely because each leaf has a small probability. Gate input events can share leaves even when the basic leaves are independent. Independence of A, B, and C therefore does not make the composite events A-and-B and A-and-C independent.

Quantification also needs compatible horizons and meanings. A one-hour component failure probability is not interchangeable with a per-request unavailability or a rate per hour. A static tree describes combinations within its chosen event definitions; order-sensitive recovery and standby behavior can need a dynamic model. Parameter uncertainty and missing common causes can dominate the approximation error from overlap. Use the tree to identify which assumptions matter, then collect evidence for them instead of reporting many decimal places from unsupported leaf numbers.

Walk through an incident and ask which basic events were true, which gate first became sufficient, and which mechanism the tree omitted. Record successful failover as well as failure: a redundant path may exist but fail to activate or lack capacity. A change that removes one cut set can create another dependency through its control plane. Review the logic when architecture or operating mode changes. A fault tree is useful because its assumptions can be inspected, not because naming gates turns uncertain architecture into a certified reliability figure.

The probability lab handles one special threshold case. Reset, set BOTH p=0.1 and n=3, interpret a success as a component failure, and predict P(at least two failures)=0.028 before Play or Step. Reset and re-set BOTH p=0.2 and n=3; predict 0.104. The exact binomial bars assume identical independent trials and do not build a fault tree, track shared causes, or sample incidents. They illustrate overlapping two-failure combinations in a symmetric case; use the worked event algebra for the different leaf probabilities below.