Event tree probability calculation: paths, roll-up, and checks

For a complete event tree, multiply the initiating-event frequency by every success or failure probability along a terminal path, then add only disjoint path frequencies that share the same outcome. In the worked cooling-water example below, four paths sum back to the initiating frequency of 0.04 per year; the three paths labeled “Cooling unavailable” roll up to 0.01264 per year. That reconciliation is the first calculation check, not an optional finishing touch.

Scope and terms before the arithmetic

Event tree analysis is a forward, inductive method: start with a defined initiating event, order the functions that respond to it, and follow their success or failure branches to an end state. IEC 62502:2010 covers qualitative and quantitative analysis of consequences from an initiating event. The NRC’s Module E describes the practical structure as one initiating event followed by ordered headings and success/failure branching; it also says physically meaningless combinations may be pruned.

Three quantities must not be mixed:

• Initiating frequency is how often the challenge is modeled to occur. Here f0 = 0.04 per year, with units of inverse years.
• Branch probability is the dimensionless chance of success or failure when that function is challenged. Schematex’s p: value is the failure probability; the success branch is 1 - p.
• Sequence frequency is the initiating frequency multiplied by the branch probabilities on one terminal path. It retains the initiating frequency’s per year unit.

This example is a calculation tutorial, not a plant model. “Primary cooling-water supply lost” and every numerical input are fictional. The functions are deliberately sequential: automatic transfer must succeed before the standby train is asked to start, and the train must start before required flow can be established. Once a function fails, later questions are pruned because they no longer describe this simplified success path.

Inputs and assumptions

Input	Meaning	Value
f0	frequency of primary cooling-water supply loss	0.04 per year
p_XFER	automatic transfer failure probability per challenge	0.05
p_PUMP	standby-train start failure probability per challenge	0.10
p_FLOW	required-flow failure probability per challenge	0.20
mission boundary	one response to one initiating event, with no repair during the sequence	fixed
dependence model	fixed, mutually independent branch outcomes in this tutorial	assumed

The corresponding success probabilities are 0.95, 0.90, and 0.80. Those complements are exact for the stated inputs. The values are not field data, design targets, failure rates, or recommendations.

The independence assumption makes the multiplication reproducible but narrow. NRC guidance treats split fractions at a branch as potentially conditional on the path used to reach it and requires dependencies to be represented. A real transfer, pump, and flow path may share power, controls, suction, maintenance, environment, instrumentation, or human actions. Multiplying three marginal probabilities as though those dependencies did not exist can materially understate or overstate the outcome frequency.

Reproducible Schematex source

eventtree "Cooling-water transfer demand"
  initiating LOSS "Primary cooling-water supply lost" freq: 0.04
  function XFER "Automatic transfer succeeds" p: 0.05
  function PUMP "Standby train starts" p: 0.10
  function FLOW "Required flow established" p: 0.20
  outcome s s s -> "Cooling maintained"
  outcome s s f -> "Cooling unavailable"
  outcome s f * -> "Cooling unavailable"
  outcome f * * -> "Cooling unavailable"

This source was validated and rendered with Schematex 1.0.9 on August 15, 2026. In its event-tree syntax reference, s follows a success leg, f follows a failure leg, and trailing * tokens prune functions that are not queried. The renderer computes each path frequency, sums identical outcome labels, and identifies the largest-frequency path.

Calculate all four sequence frequencies

For each terminal path, multiply f0 by only the branch terms actually traversed. A pruned * contributes no probability factor.

Sequence 1: all three functions succeed

f_S1 = f0 × (1 - p_XFER) × (1 - p_PUMP) × (1 - p_FLOW)
     = 0.04/yr × 0.95 × 0.90 × 0.80
     = 0.02736/yr

Sequence 2: flow is not established

f_S2 = f0 × (1 - p_XFER) × (1 - p_PUMP) × p_FLOW
     = 0.04/yr × 0.95 × 0.90 × 0.20
     = 0.00684/yr

Sequence 3: the standby train does not start

f_S3 = f0 × (1 - p_XFER) × p_PUMP
     = 0.04/yr × 0.95 × 0.10
     = 0.00380/yr

FLOW is pruned on this path. Multiplying by either 0.80 or 0.20 here would split a sequence that the model says has already terminated.

Sequence 4: automatic transfer fails

f_S4 = f0 × p_XFER
     = 0.04/yr × 0.05
     = 0.00200/yr

Both later functions are pruned. The four results now form a mutually exclusive set:

Path	Pattern	End state	Frequency
S1	s s s	Cooling maintained	0.02736/yr
S2	s s f	Cooling unavailable	0.00684/yr
S3	s f *	Cooling unavailable	0.00380/yr
S4	f * *	Cooling unavailable	0.00200/yr

Roll up the outcome and reconcile the tree

Because S2, S3, and S4 are disjoint paths with the same end-state label, their frequencies may be added:

f_UNAVAILABLE = f_S2 + f_S3 + f_S4
              = 0.00684/yr + 0.00380/yr + 0.00200/yr
              = 0.01264/yr

The same result follows from the complement of the all-success path, conditional on the initiating event:

P(unavailable | initiating event)
  = 1 - (0.95 × 0.90 × 0.80)
  = 1 - 0.684
  = 0.316

f_UNAVAILABLE = 0.04/yr × 0.316 = 0.01264/yr

So 31.6% is a conditional probability given the initiating event, while 0.01264 per year is the modeled average outcome frequency. Neither number says a loss will happen on a predictable calendar schedule.

Finally, add every leaf, including the maintained outcome:

Σ f_path = 0.02736 + 0.00684 + 0.00380 + 0.00200
         = 0.04000/yr
         = f0

That conservation check passes. If a supposedly complete binary tree does not sum to its initiating frequency, inspect for a missing path, an overlapping outcome pattern, an incorrect complement, or a probability factor applied after pruning.

Review checklist and common failure modes

Before using an event-tree result, check the model and arithmetic together:

1. Define one initiating event and keep its frequency unit visible in every sequence calculation.
2. State whether each input is a success probability or a failure probability. In this Schematex source, every p: is failure.
3. Order functions according to physical sequence and dependency, not just drawing convenience.
4. Confirm every retained path is physically meaningful and that each * appears only after the sequence has terminated.
5. Make the leaf set mutually exclusive and complete for the stated boundary.
6. Recalculate at least one path independently and verify Σ f_path = f0 before rounding.
7. Sum only disjoint paths when rolling several sequences into one outcome.
8. Document shared causes, conditional branch logic, uncertainty, and recovery assumptions instead of hiding them inside one convenient p value.

Common errors are treating a rate such as 0.10 per hour as a dimensionless branch probability, entering success probability where the DSL expects failure probability, multiplying independent marginal values for functions with shared support, and interpreting an average frequency as a guarantee about the next year.

Limitations and a concrete next step

Schematex 1.0.9 uses one fixed failure probability per function in this notation. It does not link branch-specific fault trees, propagate uncertainty, model repair or time dependence, or assign consequence severity. Its computed SVG makes the stated topology and arithmetic inspectable; it does not establish that the inputs or success criteria are suitable.

Paste the source into the Schematex playground and run two boundary tests. Set p_FLOW to 0: the unavailable frequency should fall to 0.00580/yr. Then set it to 1: the unavailable frequency should rise to 0.04000/yr. If either direction or the leaf-sum check fails, stop and correct the model before replacing the fictional inputs with reviewed data.