Skip to content

Probabilistic Safety Assessment

Probabilistic model — instantiates Eventual-Occurrence Containment Design

A whole-system probabilistic model that scopes exactly what counts as the adverse outcome, tests the independence assumptions simpler math takes for granted, and records the residual risk no control removes.

Where the calculator does one line of arithmetic, Probabilistic Safety Assessment (PSA, also called probabilistic risk assessment) builds the model behind the numbers. It is the systematic, whole-system study that first pins down exactly which event counts as the adverse outcome, then traces the combinations of failures that can reach it, and — crucially — asks whether those failures are really independent or share hidden common causes. Its distinctive contribution to this archetype is discipline about assumptions: the horizon-scale math only works if per-opportunity events don't secretly move together, and PSA is the mechanism that interrogates that. Its deliverable is not a single probability but a defensible residual-risk record — the risk that remains after every prevention control, written down and owned rather than rounded to zero.

Example

An offshore oil platform is assessed for a loss-of-containment event: a hydrocarbon release large enough to threaten the crew. The team first defines the adverse outcome precisely (a release above a stated rate reaching an occupied area), because "a leak" is too vague to model. They build event and fault trees down to component failure rates, then take the step that separates an assessment from a spreadsheet: they hunt for common-mode couplings — the two "independent" gas detectors sharing one power bus, the redundant pumps serviced by the same crew on the same day. Two supposedly independent safeguards turn out to fail together on a power loss, so the naive product of their failure rates was far too optimistic.

The output is a residual-risk figure with its assumptions attached: "roughly one event per 10,000 platform-years, dominated by common-cause power failure, and this is what remains after all preventive controls." That number — honest about what it rests on — is precisely what the design must contain rather than pretend away.

How it works

  • Define the outcome sharply. State the exact end-state being assessed, with thresholds; an unscoped "failure" cannot be quantified or compared.
  • Model the paths to it. Assemble event and fault trees from component and human failure data, down to the resolution the decision needs.
  • Attack the independence assumption. Systematically look for common-cause and common-mode couplings that make "independent" safeguards fail together — the step that most changes the answer.
  • Record the residual, with provenance. Publish the risk remaining after prevention as an owned record with its assumptions and dominant contributors, not a bare number.

Tuning parameters

  • Scope boundary — how much of the system and how many outcome types are in the assessment. Wider scope catches cross-system couplings but explodes effort and delays the answer.
  • Model resolution — how deep the fault and event trees go. Finer resolution finds subtle paths but demands data that may not exist, inviting false precision.
  • Dependence treatment — how aggressively common-cause failure is modelled (explicit common-cause factors versus assumed independence). This is the highest-leverage dial and the one most often set too optimistically.
  • Data sourcing — generic industry failure rates versus plant-specific history. Generic data is available but may not fit; specific data is scarce but honest.
  • Residual-risk expression — point estimate, distribution, or bounded range, and how conservatively the uncertainty is carried into the record.

When it helps, and when it misleads

Its strength is that it is the only mechanism here that questions the arithmetic instead of just performing it: it exposes the shared-cause couplings that turn a reassuring product of small probabilities into a fiction, and it produces a residual-risk record the whole containment posture can be sized against and audited. It is what turns "we have three independent safeguards" into an honest statement about whether they are actually independent.

Its failure modes are those of any large model. It can convey false precision — a tidy 10⁻⁴ resting on a model riddled with unmodelled dependencies, historically the classic way safety studies have overstated how independent their safeguards were.[1] It is expensive and can lag the system it describes. And it is the most temptingly run backwards: calibrating assumptions until the residual risk lands under a pre-chosen "acceptable" threshold, so the assessment ratifies a decision instead of testing it. The discipline that guards against this is to make the dependence assumptions and dominant contributors the headline — not the single number — and to treat the residual-risk record as a live document, revisited as failure data and the system itself change.

How it implements the components

  • adverse_outcome_definition — the assessment opens by scoping exactly which end-state it concerns, with thresholds; nothing downstream can be quantified without it.
  • dependence_and_mixing_assumption_check — its signature step: interrogating whether per-opportunity failures are truly independent or share common causes, the very assumption the cumulative math rests on.
  • residual_prevention_risk_record — its deliverable: the owned, provenance-tagged record of risk remaining after all preventive controls.

It does not perform the horizon-scale aggregation arithmetic — that is Repeated-Trial Probability Calculator's — nor maintain the live exposure count (Opportunity Exposure Register); and it designs no containment boundary, safe state, or recovery — those belong to siblings such as Automatic Isolation Trip and Degraded-Mode Runbook.

Notes

PSA and Repeated-Trial Probability Calculator are split by design: the calculator assumes independence and computes fast; the assessment questions independence and computes slowly. Using the calculator's tidy number without PSA's dependence check is the single most common way this archetype's math goes confidently wrong. Note the neighbour boundary too — PSA quantifies and records residual risk; it is neither the independent third-party sign-off (an assurance review) nor the fault-tree technique itself, which is one tool it may use.

References

[1] Common-cause failure — when components assumed to fail independently in fact fail together because they share a cause (a power source, a design flaw, a maintenance crew). Underrating it is the classic way a probabilistic assessment overstates how independent its safeguards are. ↩