The e-stop that cut nothing

The emergency-stop loop was wired, tested, and signed off. The relay clicked when you slammed the button. And on the one day it mattered, the bus stayed hot — because the loop's cut-list referenced a channel name that didn't exist. This is a near-miss autopsy.

The commissioning run

A colleague's team was commissioning a new propulsion-adjacent rig: one 28 V bus channel feeding the DUT, a valve command line, the usual sensors. Safety review had done its job — on paper. There was an interlock loop. It had a name, a type, a hardware e-stop button with a satisfying mechanical thunk, and a cut-list: the set of channels the loop would de-energize when fired.

During a sequence dry-run, a sensor reading went sideways and the operator did exactly what training says to do: he hit the e-stop.

The relay fired. The lamp changed state. The logs recorded an interlock event. And the 28 V bus stayed live, feeding a runaway condition for another eleven seconds until someone killed the supply manually at the breaker.

Nobody was hurt. The DUT survived, barely. But here's the part that should bother every engineer reading this: every observable signal said the protection had worked. The relay clicked. The event was logged. If the runaway hadn't forced a manual breaker pull, the team would have written up a successful e-stop test.

The autopsy

The incident review found the cause in under an hour, because it was a single line of configuration. The interlock's cut-list read:

{ "name": "estop_loop_1", "type": "hardware_estop",
  "cuts": ["bus_pwr"] }

The channel was called bus_power. Somewhere between the electrical engineer's naming and the controls engineer's config, four characters went missing. The runtime, encountering a cut-list entry that resolved to nothing, did what most runtimes do: it skipped the unknown name and cut everything else on the list. The list had one entry. So it cut nothing — cleanly, quietly, and with a full audit trail.

Why nobody caught it

Because humans verify presence, not resolution. Every reviewer asked "is there an interlock, and does the button work?" Both answers were yes. Nobody asked the only question that mattered: does every name in the cut-list resolve to a channel that exists? That's not a question a person should be answering at 11 pm with a multimeter. It's a question a linter answers in a millisecond, every time, without fatigue:

$ standguard.py lint bench.json --strict

[ERROR  ] interlock.cuts       interlocks['estop_loop_1']: cuts references undefined channel 'bus_pwr' (did you mean 'bus_power'?)

1 error · verdict: BENCH UNSAFE TO POWER (exit 1)

This is the rule I think about when people ask why the catalog treats interlock.cuts as an error and not a warning. A bad pin might get caught by a careful power-up. A hollow interlock gets relied upon.

The three-line takeaway

• References must resolve. Any name in any safety-relevant list that doesn't point at a defined thing is not a typo — it's a hole in the protection system.
• Audit trails aren't protection. The logs said the interlock fired. The logs were accurate. The bus stayed hot anyway.
• Test the negative case. If your e-stop test only confirms the relay clicks, you've tested the button, not the protection. Fire it under load and verify what actually de-energizes.

Your turn

If you've got a near-miss like this — the protection that existed on paper, the interlock that fired into the void — I want the physics, anonymized as much as you need. This story became a catalog rule. Yours could be the next one.