The check that cannot fail is not a check

Teams running agent operations add gates as they scale: a rule that blocks an unsafe write, a check that refuses a bad merge, a monitor that pages someone before damage happens. Each one is added for a real reason, and each one earns trust the first time it catches something.

That trust is the problem. Once a gate has proven itself, nobody re-verifies it. It sits in the stack, passing quietly, and a quiet gate looks exactly like a working one.

#Three reasons a gate can show zero firings

Not every quiet gate is broken. But "quiet" collapses three very different states into one signal, and only one of them is actually fine.

A firing count answers "has this happened," not "can this happen." Those are different questions, and only the second one tells you whether the gate still does its job.

#The check that certifies your gate can inherit the same defect

There is a sharper version of this trap, and it is structural rather than a matter of team diligence: a test written to certify a gate is built against the same assumption the gate itself relies on. The same path, the same layout, the same "this is how it will always look."

When the underlying system moves, the gate goes stale and its own test suite stays green, because the test was never independent of the premise that broke. A passing test suite for a dead gate is not reassurance. It's the same blind spot, certified.

#The fix is a positive control, not a bigger dashboard

The way out is not more logging or a longer retention window on the firing count. It's a deliberate, cheap check: manufacture the exact bad case the gate exists to catch, run it against the gate that actually executes at the point of action (not a copy in a docs folder, not the version in the design review), and confirm it gets refused.

• If it fires: the gate is alive. Keep it, and note the date you proved it.
• If it doesn't fire: you just found a real gap, cheaply, before an incident found it for you.
• If you can't even construct the bad case: that's worth writing down too; it usually means the gate's premise has quietly become irrelevant, not that it's succeeding.

The absence of a firing is not the answer to whether a gate still works. It's the question nobody asked yet.

#What to check this week

1. List the gates, checks, and hooks your agent operations actually depend on.
2. For each one, ask: when did it last fire on a real case, not a self-test?
3. Where the answer is "never" or "not recently," build the smallest positive control that would trigger it, for real, against the live enforcement point, and run it.
4. Treat a gate that won't fire as a finding to route, not a metric to celebrate.

Verification only earns trust when someone has recently proven it can fail. A gate that has only ever passed hasn't been verified. It's been assumed.

See how EP treats verification as an operating discipline, not a one-time build.