Y4.04.3Verifiable safeguard statedesign

A lock or interlock's protective position needs to be actively confirmable, not just assumed

Aliases: verifiable safeguard state · hazardous energy control

What it is

A verifiable safeguard state means the system or the operator can actively confirm whether a cover, lock, interlock, key, or software permission is genuinely in its protective position right now — not simply assume protection exists because a control looks intact. Looking present and actually being present are two different things; the first is an appearance-based inference, the second requires evidence.

Why it happens

Any protective layer wears over time, can be bypassed, or can falsely report a normal state like "closed" because its own detection sensor has failed. Without an independent way to verify that state, this kind of latent failure never surfaces on its own — it sits quietly until the moment protection is actually needed, a hazardous condition arises, and the safeguard fails to respond because it had already stopped working long before. Only then does the failure become visible, usually too late. Independent position sensing (not relying on a signal loop from the guarded object itself), system self-test, and periodic physical proof testing each shorten, from a different angle, the gap between when a failure occurs and when it is discovered — giving that failure a chance to be found in a harmless moment rather than at the scene of an incident.

Where it stops holding

The detector itself can share a failure cause with the very guard it is meant to detect — the same power supply feeding both the guard and its position sensor means a power fault takes both down together, and at that point "the sensor reports closed" is the least valuable piece of evidence available, because it has lost its independence from the true state. A switch reporting "closed" as an electrical signal also does not by itself prove hazardous energy has actually been isolated — closure may be only a contact signal, while the mechanical linkage may have failed to actually drive isolation due to wear or misalignment. How often to test and by what method depends on the specific hazard type and the typical failure mode of that particular safeguard; there is no universal test interval.

Applying it

Every proof test should preserve concrete evidence of what was actually done and what result was obtained — a measured isolation voltage, an actually triggered interlock record — rather than a checkbox marked "inspected" in a system, which is not evidence by itself.

  • Continuously display the guard's actual physical position, the confidence of the detection itself, whether it is currently bypassed, and the time of the last physical proof test on the interface, and immediately restrict any operation depending on that layer the moment an anomaly is found, rather than letting operations continue as usual.
  • How to check: inject a jammed mechanism, a shorted sensor producing a false "closed" signal, a door left ajar while the sensor still reports closed, and a deliberately set bypass, and verify the system correctly reports the guard as no longer effective in each case, rather than being fooled by a surface signal into showing everything is fine.

Related

  • Same group: Y4.04.1 Intent-discriminating safeguards · Y4.04.2 Consequence-matched safeguard strength
  • Nearby: Y3.10 Parameter limits and safety interlocks · Y8.03 Availability of maintenance information
  • Search terms: Verifiable safeguard state · hazardous energy control · safety-critical work

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Y4.04.3