A critical control needs its own barrier so a casual touch and a real command take different paths

What it is

Guarding a critical control means it must be treated differently on screen from routine controls, so a casual touch and a genuine intent to act follow different paths. Which physical safeguard device fits which equipment is an engineering selection question; what belongs here is the slice of mistouch risk the control interface itself manufactures — the same screen, the same operating flow, whose own layout can turn a routine action into a hazardous one. That slice cannot be fixed by bolting on a cover; only interface design itself removes it.

Why it happens

Much of the mistouch risk in a control room or an operating screen does not come from a slipped hand or a misread label — it comes from three situations the interface itself creates. A high-consequence control crowded into the same region as routine ones, without enough visual distinction, gets caught by an operator moving quickly on positional memory. Adjacent controls with very different functions can look nearly identical, distinguishable only by reading the label carefully. And the easiest one to miss: state carryover — an operator selects or arms an object on one screen, navigates away without that pending state being cleared, and a tap that would have been harmless on return becomes an execution because the leftover state is still attached. All three share one precondition: they only arise because the interface lets an operator move quickly across multiple screens and controls. A physical guard alone stops collisions and stray presses; it cannot stop a state left behind by switching screens.

Where it stops holding

State carryover only exists on interfaces that rely on screens and software state to track a "currently selected / pending" object; a purely hardwired physical panel, where each button maps to exactly one fixed action, carries no software state across to a next screen, so this mechanism does not apply there. Visual similarity and crowded layout are triggers, not sufficient conditions on their own — the same crowded layout can slow down an unfamiliar operator who hesitates rather than acting quickly. The risk actually concentrates in highly practiced operators, who rely more on positional memory and check each item less.

Applying it

Bind any "pending" or "selected" state to the specific screen it was created on, and clear it automatically the moment the operator navigates away — it must not survive across screens. Give high-consequence controls a combination of visual features (shape, colour, and position all differing at once, not just one swapped out) that cannot be approximated by an adjacent routine control; relying on colour alone or position alone is too easy to replicate in a crowded layout.

• How to check: stage a scenario where an object is selected, the screen is switched away and back, and verify the pending state has been cleared; separately, build a screen where adjacent controls are deliberately similar in appearance and measure misselection rate among practiced operators working at real operating pace — not a slowed-down, carefully-checked pace.

Related

• Same group: Y3.05.2 Risk-proportionate control protection · Y3.05.3 Emergency access through safeguards
• Nearby: Y4.04 Inadvertent-operation prevention devices · Y3.10 Parameter limits and safety interlocks
• Search terms: control guarding · state carryover · visual similarity error · interface-level inadvertent operation