Skip to content

Bow-Tie Path Analysis

Model — instantiates Conjunctive Path Assurance

Puts one unwanted event at the centre and lays out the threat paths into it and the consequence paths out of it, making the barrier on each path explicit.

The computational tools tell you which conjunctions are possible or how likely; Bow-Tie Path Analysis does the complementary job of making the whole picture legible to everyone at once. It fixes a single undesired central event — the "knot" of the bow-tie — then draws the threat paths flowing into it on the left and the consequence paths flowing out of it on the right, and on every one of those paths it names the barrier that is supposed to stop the route there. Its defining move is being barrier-centric and two-sided: prevention barriers on the left keep the event from happening, recovery barriers on the right keep it from escalating, and laying them out this way makes an under-defended path — one with a single barrier, or none — impossible to miss at a glance.

Example

An offshore platform builds a bow-tie around the central event loss of hydrocarbon containment. On the left, threat paths run in: corrosion (prevention barrier: inspection programme), overpressure (barrier: pressure relief valve), dropped object (barrier: lift plan and exclusion zone). On the right, consequence paths run out: pool fire, then explosion, each with recovery barriers — gas detection triggering emergency shutdown, deluge, muster and evacuation. Drawing it reveals two things immediately: the overpressure path is defended by a single barrier, and one gas-detection system sits on several consequence paths at once — a shared barrier whose independence now deserves a hard look. Each barrier gets a named owner, and the thin path gets a second, independent safeguard.

How it works

Fix the central event at the right level of abstraction; brainstorm the threat paths that can reach it and the consequence paths that can follow; place each existing or required barrier on its path, tagged as prevention (left) or recovery (right); note, for each, the condition under which it is actually effective and the escalation factors that could defeat it. It is deliberately qualitative — it does not compute cut sets or probabilities. Its contribution is spatial and shared: a single readable map of where every barrier sits relative to the one event the organisation most wants to avoid.

Tuning parameters

  • Central-event granularity — how broadly the knot is defined. A broad event captures more paths but blurs which barrier does what; a narrow one is crisp but needs several bow-ties to cover the hazard.
  • Barrier-credit strictness — what you allow to count as a barrier (only independent, auditable, demonstrably effective ones, versus every hopeful control). Strict credit yields an honest picture; loose credit flatters it.
  • Escalation-factor depth — how far you model the conditions that defeat each barrier. Deeper exposes fragile barriers but grows the diagram.
  • Prevention/recovery emphasis — how much attention goes left (stop it happening) versus right (limit the damage). Reflects whether the risk is better managed before or after the central event.

When it helps, and when it misleads

Its strength is legibility: a non-specialist can read a bow-tie, see which paths are thinly defended, and know who owns each barrier — which makes it excellent for aligning a whole team and for communicating risk upward. Its failure mode is that it is qualitative: it shows that barriers exist, not whether they are truly independent or how probable the conjunction is, and a tidy, full-looking diagram can imply more protection than the barriers actually deliver. The classic misuse is drawing barriers that look reassuring to pass a review rather than verifying they hold — "barrier theatre." The discipline is to pair every credited barrier with evidence of independence and effectiveness, and never to let diagram completeness stand in for barrier integrity.[1]

How it implements the components

  • source_target_hazard_boundary — the central event plus its threat sources (left) and consequence targets (right) fix the span of the hazard the analysis covers.
  • path_break_or_interlock_requirement — each prevention barrier on a threat path is a required break that keeps that route from reaching the central event.
  • safe_state_and_recovery_path — the recovery barriers on the consequence side lay out the routes back to a safe state after the event fires.

It stays qualitative: the minimal_activating_conjunction_set and its probabilistic_dependence_profile come from Fault Tree with AND-Gate Logic and Minimal Cut-Set Enumeration, and the common_driver_and_independence_check that tests whether its barriers are genuinely independent comes from the Common-Cause Dependency Audit.

Notes

The bow-tie is often the front-end that decides which deeper analyses are worth running: the left barriers point at fault trees to build, the right paths at event-tree or recovery analysis, and shared barriers at a common-cause audit. Read it as an organising map, not as the calculation itself.

References

[1] The Swiss cheese model (James Reason) pictures each barrier as a slice with holes; an accident occurs only when the holes across successive slices happen to line up. It is a faithful image for a bow-tie — a complete route exists precisely when every barrier on a path is defeated at once — and a reminder that barrier count matters less than whether the holes are independent. ↩