Does an event tree have to contain probabilities?

No. A qualitative tree can clarify sequences and outcomes before reliable numerical estimates exist.

Is event tree analysis a decision-tree machine-learning algorithm?

No. Here the tree represents event sequences and response outcomes, rather than a fitted prediction rule.

Can branches be dependent?

Yes. The quantitative model must account for that dependence, often through path-specific conditional probabilities or supporting analysis.

AI Glossary / Data engineering and architecture / Intermediate

Event tree analysis

Definition

Event tree analysis is a forward-looking method for tracing possible outcomes after an initiating event. It branches according to subsequent events or the success and failure of responses, making the paths to different consequences explicit.

What it means

Start with something that has happened, such as a service interruption. Ask what happens next: does automatic recovery work, and if it does not, can a manual response restore service in time? Each answer leads to another branch or an end state.

The resulting tree is a model of selected sequences. It does not claim to predict which path a particular incident will take. It can be qualitative, describing outcomes, or quantitative, assigning probabilities or frequencies where evidence supports them.

This differs from fault tree analysis, which starts with an unwanted top event and examines combinations of causes that could produce it. Event trees proceed from an initiating event towards consequences. The two methods can complement each other, with a fault tree helping estimate a response failure used in an event tree.

How it works

Define the initiating event, analysis boundary and relevant outcome categories. Identify the responses or developments that affect what happens next, and put them in a meaningful sequence. A branch may represent success or failure, but models can also distinguish several outcomes where a binary split is inadequate.

Make alternative branches at each split mutually exclusive and collectively exhaustive for the modeled possibilities. Document conditions under which a later branch is relevant; not every path requires every response.

For quantitative analysis, use probabilities conditional on the preceding path. Multiply along a path to obtain its conditional outcome probability. Sum probabilities of mutually exclusive paths when they represent the same outcome category.

If an initiating-event frequency is available, combine it with the appropriate conditional outcome probability to estimate an outcome frequency under the assumptions. Keep uncertainty, dependencies and omitted scenarios visible. A neat tree does not compensate for unsupported numbers.

Three practical examples

A digital service team traces whether automatic recovery and a later manual response prevent a prolonged outage after a failure.
A logistics team explores what follows a missed collection, including alternative transport and customer rescheduling outcomes.
An AI operations team maps what happens after an incorrect generated answer: whether detection, review and correction occur before the answer is used.

Think of it this way

Think of a branching travel plan after a train is canceled. One branch uses an available replacement service; another tries a different route; a final branch arrives too late. The tree clarifies how the outcome depends on what happens next.

The analogy does not justify assigning equal chances to every branch. Availability and delays can be related, especially when the same disruption affects several alternatives.

Worked example

Calculating an outage outcome

In an invented service model, automatic recovery succeeds in 90% of initiating failures and fails in 10%. Given automatic recovery has failed, the manual response succeeds before the defined deadline with probability 0.8 and fails with probability 0.2.

The three mutually exclusive end-state probabilities, conditional on an initiating failure, are 0.90 for automatic recovery, 0.10 × 0.80 = 0.08 for timely manual recovery, and 0.10 × 0.20 = 0.02 for missing the deadline. They sum to 1.00.

If the initiating failure frequency is assumed to be five per year, the modeled frequency of missing the deadline is 5 × 0.02 = 0.1 per year. That is an expected frequency under the model, not a prediction that the event happens exactly once every ten years.

The manual-failure value must apply after automatic recovery has failed. Substituting an unrelated overall manual-failure rate could understate the risk when both responses share a dependency.

Illustrative case study

A fictional online course platform analyses interruptions during live workshops. Its first event tree assumes that automatic failover and an operator's manual recovery are separate protections. A review finds that both need access to the same configuration service.

The team revises the paths and assumptions to account for that shared dependency. It also distinguishes restoring the application from restoring the live session before participants leave; the relevant end state is a business outcome, not merely a server responding.

A rehearsal records whether each response completed within the defined window. Those observations inform later model revisions, while rare conditions remain explicitly uncertain. The case illustrates disciplined scenario analysis. It does not provide reliability estimates for a real platform.

Common misconceptions and mistakes

Each branch has a fifty-fifty chance. Branch structure does not determine probability.
Multiplying marginal probabilities is always valid. Dependencies require the appropriate conditional probabilities.
A low-frequency outcome is guaranteed not to occur soon. Frequency estimates do not schedule individual incidents.
The tree covers every possible failure because it has many branches. Completeness depends on scope and scenario identification.

Business use

Use event trees to make response assumptions discussable. They can reveal that a planned fallback is unavailable on the very paths where it is needed, or that a successful technical response still misses the business deadline.

Separate evidence from judgment when assigning branch values. Record where estimates came from, their applicable conditions and how uncertainty affects conclusions. Sensitivity analysis can show which assumptions most influence the result and where better evidence would be valuable.

For AI workflows, avoid assigning reassuring detection probabilities merely because a human review step exists. Define what the reviewer can observe, when review occurs and which errors the step can realistically detect.

Check your understanding

Automatic and manual recovery both require the same failed network. Can their failure probabilities simply be multiplied as though the two responses were independent?

Answer: No. The shared dependency changes the probability of manual recovery given the preceding failure. Model that condition explicitly before calculating the path.

Related terms

Conditional probability
Sensitivity analysis
Reliability
Fault tree analysis
initiating event
risk analysis
common-cause failure

Learn next

Read conditional probability and fault tree analysis. Draw a small tree for a routine service interruption, label the deadline defining success, and identify one shared dependency between the responses.

Conditional probability

Sources

Abdelghany, Ahmad, Tahar and Nethula, ETMA: A New Software for Event Tree Analysis with Application to Power Protection: https://arxiv.org/abs/2006.12383. Primary research description of event-tree construction and probabilistic analysis.

US Nuclear Regulatory Commission, NUREG/CR-6101, Appendix A.2.3: https://www.nrc.gov/reading-rm/doc-collections/nuregs/contract/cr6101/cr6101.pdf. Indexed primary text supports path-probability multiplication; direct full-document access was unavailable. All probabilities and business cases in this entry are invented teaching examples.

Previous: Event store Next: Evidence