Event trees: how do response sequences become outcome frequencies?

What question does an event tree answer?

Imagine a cooling supply is interrupted. One response might restore cooling; another might shut equipment down before damage develops. These are different outcomes. An event tree makes their order and conditions explicit instead of reducing the whole situation to a single “protected/unprotected” label.

The method is useful when the question concerns what happens after a challenge: which responses are called upon, which combinations lead to a particular outcome, and where missing information matters. Fault trees can examine why an individual response fails; the event tree retains the sequence perspective. Both appear in probabilistic risk assessment, but neither turns unsupported assumptions into evidence. NRC probabilistic risk assessment

Start with a precise boundary

Record the initiating event, time basis, operating condition and terminal outcomes before drawing branches. “Cooling unavailable” is too broad if the intended event is specifically “loss of the normal cooling supply while equipment is operating.” State what counts as recovery and what counts as shutdown. A shutdown that protects equipment is not the same as uninterrupted operation.

Also decide when a response is relevant. If cooling has already been restored, the example below ends that path. It does not invent a shutdown demand after successful restoration.

A complete three-path example

The following numbers are invented for teaching; they are not measurements from a vessel or results from any software product.

Assume:

• Normal cooling is interrupted at an illustrative frequency of 0.04 per year.
• A recovery response succeeds on 95% of these demands.
• If recovery fails, a protective shutdown succeeds with conditional probability 0.90.
• The defined responses and terminal outcomes cover all cases within this deliberately simplified model.

There are three terminal paths:

1. Cooling restored: 0.04 × 0.95 = 0.038 per year.
2. Recovery fails, shutdown succeeds: 0.04 × 0.05 × 0.90 = 0.0018 per year.
3. Recovery and shutdown both fail: 0.04 × 0.05 × 0.10 = 0.0002 per year.

Their sum is 0.04 per year, matching the initiating frequency. This is a useful arithmetic check because the paths were defined as mutually exclusive and collectively exhaustive within the example. Passing that check does not establish that the real-world scenario list is complete.

Why “conditional” matters

The shutdown input means “probability of successful shutdown given that recovery failed in this scenario.” It is not automatically interchangeable with a general shutdown-availability figure from another population or test condition.

Multiplying conditional branch probabilities follows the structure of the example; it does not require pretending the two functions are independent. If only unconditional reliability figures are available, dependencies must be considered before using them as branch values. Shared power, shared sensing, environmental conditions or human actions may change the probability on a particular path. A common cause cannot be removed simply by drawing two separate boxes.

What does the smallest number mean?

Here, 0.0002 per year is the modeled frequency of one specifically defined sequence. It is not a measured accident rate, a severity measure, or the probability of every possible damaging event. A frequency and a probability have different meanings; converting between them requires a stated time model.

Nor does the calculation prove that the shutdown deserves safety credit in an actual installation. That requires suitable evidence about its function, conditions, reliability and dependencies. The numerical example demonstrates bookkeeping, not an acceptable-risk decision.

Choose a success criterion that includes time

A response succeeds only if it achieves the defined function under the conditions of the sequence. “Pump started” may be too weak if the actual requirement is adequate flow before a thermal limit is reached. A response that works after the available time has expired belongs on a different outcome path from timely recovery. Define mission duration as well: starting successfully does not prove sustained service for the required period.

The branching order should reflect the logic being modelled, not merely the order in which boxes were drawn. Some actions occur in parallel; some depend on information generated by earlier events. A simple static event tree can still be useful, but its treatment of timing must be stated. Where changing conditions or feedback determine success, a more detailed time-dependent model may be required rather than adding arbitrary branches to a static diagram.

Separate the initiating population from branch performance

An initiating frequency needs a defined population and exposure basis. “Per ship-year” differs from “per transfer” or “per start demand”. If an event is modelled per operation, annualisation requires an explicit number of relevant operations. For an invented example, 200 operations per year and an assumed initiating probability of 0.0002 per operation produce an expected initiating count of 0.04 per year under the stated model. The multiplication does not establish that the operations are identical or the input probability is supported.

Branch evidence should also match the path. Recovery performance during normal electrical supply may not represent recovery after a shared supply failure. Splitting initiators into distinct categories can make that dependence clearer, provided categories do not overlap and their frequencies are consistently defined. Do not count the same initiating occurrence in two categories and then add both trees as though they were independent contributions.

Link fault trees without double-counting dependencies

A fault tree can supply a model for why a response fails, but its output must correspond to the event-tree branch's condition and time basis. If the initiating event already establishes that a power supply is lost, the branch model should account for that known state. Using an unconditional system-failure probability can give credit to a supply that the sequence has already removed.

Shared events need consistent identities across the model. Two diagrams that both contain the same breaker failure do not represent two independent failures. The analyst should trace how common support systems, environmental challenges and human actions enter several branches. The aim is a coherent model of one sequence, not a collection of separately calculated reliability numbers. Numerical precision cannot compensate for contradictory conditioning.

Test the conclusion with an explicit sensitivity range

For the earlier three-path structure, suppose an exploratory analysis varies initiating frequency from 0.02 to 0.08 per year, recovery-failure probability from 0.02 to 0.10, and shutdown-failure probability conditional on failed recovery from 0.05 to 0.20. Multiplying the lower endpoints gives 0.00002 per year; multiplying the upper endpoints gives 0.0016 per year. This eighty-fold range shows the effect of the chosen input envelope, not a measured variation in accident experience.

The endpoints are illustrative assumptions and may not be jointly plausible in a real system. They are not a 95% confidence interval or a probability distribution. A better decision study asks which combinations are defensible, whether a proposed action remains useful across them, and which evidence would most reduce decision-relevant uncertainty. Changing one input at a time can help explain the model, but can miss interactions or correlations among inputs.

Zero observed failures do not establish a zero branch probability

Suppose a fictional response has twenty independent, comparable demands and no observed failures. The sample failure fraction is zero, but the underlying failure probability is not thereby proved zero. Under an identical Bernoulli-demand model, the probability of observing no failures is (1 − p)^20. Solving (1 − p)^20 = 0.05 gives p ≈ 0.139, the one-sided 95% exact upper bound for this particular zero-failure case.

NIST's exact-binomial confidence-limit documentation provides the statistical framework. The calculation is an authored illustration, not a suitable probability assignment for a real barrier. Independence, comparable demand conditions, complete failure reporting and the definition of failure all matter. A confidence procedure's coverage should not be rephrased as a 95% probability that this fixed but unknown p lies below the bound.

Aggregate outcomes without losing their meaning

Several mutually exclusive paths may end in the same consequence category, in which case their sequence frequencies can be added consistently. But categories such as equipment damage, loss of propulsion and injury can overlap. Adding their totals without checking the event definitions may double-count occurrences. Keep the sequence identifier, terminal state and consequence model linked, and state whether the result counts events, affected vessels or another quantity.

A rare branch is not automatically the highest priority or the lowest priority. Consequence severity, uncertainty, feasible measures and the decision context remain relevant. The event tree's useful output is a transparent sequence model with traceable assumptions, not an automatic declaration of acceptable risk. Preserve qualitative paths even when reliable probabilities are unavailable, and mark them as unquantified rather than silently dropping them from the analysis.

A practical review checklist

• Are the initiating event and every outcome named precisely?
• Are the frequency units visible and consistent?
• Do success/failure branches describe the same demand and operating condition?
• Are probabilities conditional on the path where they are used?
• Are omitted paths, common causes and unavailable data stated?
• Does the report preserve the assumptions beside the result?

For a richer analysis, test which assumptions change the conclusion and what evidence could resolve them. A sensitivity comparison answers what changes in the model; it does not by itself establish what will happen in service. NASA's modeling-and-simulation guidance treats credibility and acceptance criteria as part of the model's intended use. NASA model-and-simulation standard

Sources and related reading

• NRC: Event tree
• NRC: Probabilistic risk assessment
• NASA: Standard for Models and Simulations

Related library topics: fault trees; independent protection layers; sensitivity and uncertainty. This guide explains a general method and does not give an operating or safety-approval procedure for a particular installation.