A bowtie can show a neat row of barriers between a hazard and its consequence, but each of those barriers can quietly fail for reasons that have nothing to do with the main scenario. An escalation factor - also called a defeating factor or degradation factor - names one of those reasons, so the diagram captures not just the barrier but the conditions that could undermine it. This guide explains what an escalation factor is, how escalation controls manage it, and how everyday operating signals reveal when a barrier is being defeated.
Escalation Factor in one line: An escalation factor, also known as a defeating or degradation factor, is a condition that can erode or defeat a barrier on a bowtie so that it no longer performs its protective function. Examples include a fouled sensor, a bypassed interlock, or an overdue proof test. Each escalation factor is managed by one or more escalation controls, which are safeguards aimed at the factor rather than at the main hazard, so that the barrier remains effective.
On a bowtie, the main pathways run left to right, from threats through prevention barriers to the top event and on through mitigation barriers to consequences. An escalation factor sits below a specific barrier and attacks it from the side, describing a condition under which that barrier would not work even though the main scenario has not changed. The escalation factor does not cause the hazard directly; it removes the protection you were counting on, so that when a threat does arrive, the barrier is already compromised. This is why escalation factors are sometimes called defeating factors - they defeat the barrier rather than trigger the event.
Typical escalation factors are the practical ways a barrier decays in service. Fouling or plugging can blind a level or pressure transmitter so a trip never sees the condition it should act on. A bypassed or forced interlock leaves a functional barrier switched off. A deferred or overdue proof test means there is no current evidence the barrier still works, so its assumed reliability is no longer justified. Corrosion or erosion can weaken a physical barrier such as a vessel wall or a bund. Human factors count too: an alarm that is chronically flooded or an operator response that has become routine and inattentive can defeat a procedural barrier.
Capturing these factors is what separates a realistic bowtie from an optimistic one. Without escalation factors, a diagram implies every barrier is always fully effective, which is never true over the life of a plant. By naming the specific ways each barrier can be undermined, the bowtie forces a conversation about how those conditions are prevented or detected, and it gives operations a concrete list of things to watch rather than a vague instruction to keep the barriers healthy.
For every escalation factor worth showing, a bowtie should show the escalation controls that keep it in check. An escalation control is a safeguard aimed not at the hazard but at the factor that would defeat a barrier - it protects the protection. Where fouling could blind a transmitter, the escalation control might be a scheduled cleaning or a self-diagnostic that flags a stuck reading. Where a bypass could leave an interlock defeated, the control might be a bypass management procedure with time limits, physical key control, and an alarm that a bypass is in place. Where a proof test could slip, the control is a test-scheduling and tracking system that will not let the interval quietly expire.
Good escalation controls tend to be either preventive, stopping the factor from arising, or detective, catching it quickly once it has. A cleaning programme is preventive against fouling; a stuck-signal diagnostic is detective. Both have value, and a strong bowtie often shows one of each, because prevention is never perfect and early detection limits how long a barrier stays degraded. The point is that an escalation factor left with no controls is a warning: the diagram is admitting that a known way of defeating the barrier has nothing managing it, which is precisely the sort of gap a bowtie review should surface.
It is worth keeping escalation controls conceptually separate from the barriers on the main pathway. A barrier acts in the accident sequence itself, between threat and top event or between top event and consequence. An escalation control acts off to the side, on the condition that would render a barrier ineffective. Confusing the two inflates the apparent protection, because a control that only keeps a barrier healthy is not a second, independent barrier against the hazard. Keeping the roles distinct is part of why the escalation-factor structure exists.
Escalation factors are attractive precisely because many of them leave a trace in the control system long before a scenario tests the barrier. A defeated interlock shows up as a force or override flag. A blinded or drifting transmitter can appear as a frozen value, a reading pinned at a rail, or a diagnostic fault. A slipping test regime shows up as an overdue-test status. A barrier under strain shows up as a rising demand or repeated activation. These are not hidden engineering unknowns; they are operating conditions that a monitoring system can present as they happen, which turns the abstract escalation factors on a bowtie into a live watchlist.
That reframing is useful because escalation factors are the part of a bowtie most likely to be true right now and least likely to be noticed. The main threats are rare by design, but bypasses get left on, tests get deferred under workload, and sensors foul continuously. A field that surfaces override flags, overdue tests, and abnormal signal behaviour is effectively reporting which barriers are currently being defeated, without waiting for the hazard to reveal it. Reviewing those signals against the escalation factors identified in the bowtie closes the loop between a design-stage study and day-to-day operation.
Merobix, as cloud SCADA for oil and gas, consolidates force and override flags, alarm and trip activity, and process values from many remote sites into a single browser view, so the operating conditions behind escalation factors are visible in one place. It does not draw the bowtie or decide which factors matter - that remains an engineering task - but by making bypasses, stuck signals, and rising demands easy to see across a whole field, it gives operations a direct line of sight on the defeating conditions a bowtie warned about.
A threat is a cause that can start the main accident sequence and lead to the top event, so it sits on the left of a bowtie feeding into a prevention barrier. An escalation factor does not start the sequence; it sits beneath a barrier and describes a condition that would defeat that barrier if the sequence did occur. In short, a threat causes the event and an escalation factor removes a defence against it.
Because without them a bowtie assumes every barrier is always fully effective, which is never true over a plant's life. Escalation factors make the diagram honest by naming the specific ways each barrier can decay, and they give operations a concrete list of conditions to prevent, detect, and monitor. They also expose gaps where a known defeating condition has no control managing it.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.