You push a change. The CI turns green. The lint rule passes. The eval suite reports 100%. You ship it. That's the trust.
Now consider this: a guardrail that has never fired and a guardrail that silently stopped running produce identical output. Both show green. The pipeline that was never green, the grader that can't say no, the eval result with no provenance—these are all symptoms of the same disease: we've automated our checks, but we haven't checked on our checks.
The Problem: Automating a Check Swaps the Question
Before you automated a review, the question was simple: did someone look at this? You could see the person, ask them, get an answer. After you automate, the question you think you're asking is still "did the check pass?" But the question you're actually depending on is "is the check alive?"
Almost nobody instruments the second question. In operations, we never rely on a monitoring system without a heartbeat—we alert on the absence of a heartbeat, because a dead monitor looks exactly like a system with no problems. We haven't carried that lesson to the checks that gate our code.
Consider three real examples from a recent DEV Community piece.
The Pipeline That Was Never Green
Vicente Reyes had a GitHub Actions workflow called "Deploy to DigitalOcean." It was fully wired: SSH action, secrets, jobs. The deploy job was gated on CI passing, but CI had never once gone green on main. Not flaky—never. So every deploy run showed skipped, forever. The pipeline sat permanently behind a gate that couldn't open. His line is worth keeping: "A pipeline that is silently and permanently blocked looks, from a distance, exactly like a pipeline that doesn't exist." Nothing in the Actions UI says "this workflow has not succeeded in forty runs." You have to ask.
The Grader That Can't Say No
On a thread about designing trustworthy AI evals, Heinrich Neb made a point: every grader needs a known-bad twin—an input it is supposed to reject, plus a recorded date of when it last actually rejected something. A grader that has never failed and a grader that silently stopped running print the same green. His framing: a stuck-closed gate is annoying enough that somebody investigates. A stuck-open gate just keeps saying yes.
Think about how an eval suite rots. Someone changes a prompt template and the grader's regex stops matching, so everything scores as pass. Someone renames a dataset field, the loader returns an empty list, the suite runs zero cases in 0.4 seconds and reports 100%. A provider changes a default and your grader model gets more agreeable. All three look like success.
The Score With No Provenance
The third example is from my own work with regulated systems. An eval result with no harness version, no dataset snapshot, and no prompt revision attached is not evidence; it's a self-reported claim. It's fine until the number moves. Then you can't answer whether the model got better or the suite got easier. You never had a measurement—you had a vibe with a decimal point on it.
The Core Insight: Your Checks Are Monitoring Systems
A CI workflow, a lint rule, an eval suite, an agent policy—these are all monitoring systems for correctness. They're supposed to alert you when something is wrong. But we run them with no heartbeat at all. That's the gap.
Here's the fix: treat every guardrail like a monitoring system, and instrument it with a dead man's switch. A dead man's switch is a mechanism that triggers if the system goes silent—in this case, a guardrail that stops running or stops rejecting should flag itself as broken.
The Four Things Every Guardrail Needs
None of this is exotic, but it requires discipline. Before you trust a guardrail, it needs four things:
- A known-bad input it must reject. Every check needs a case it's supposed to fail on, running alongside the real ones. If your lint rule can't catch its own canary, the lint rule isn't running. If your eval's negative control scores as a pass, the grader is broken and every other number in that run is noise.
- A recorded date of last rejection. Not when it last ran. When it last said no. A guardrail that hasn't rejected anything in four months is either protecting an unusually disciplined team or it broke in May, and those look identical on a dashboard. Put it in a column somewhere.
- A run count someone occasionally looks at. The zero-cases failure is the sneakiest one: a suite that loads an empty dataset passes fast with a perfect score. Assert on the count. If it expects 240 cases and got 0, that's a hard failure, not a 100%.
- Provenance on the result. Harness commit, dataset hash, prompt revision, model version, timestamp. Attached to the score, not sitting in a CI log with thirty-day retention. The test is simple: six months from now, can you reproduce this exact number?
How to Implement This
For CI pipelines: Add a canary test that intentionally fails. For example, a test that asserts 1 == 2 but is gated behind an environment variable like RUN_CANARY=true. Your normal runs skip it; your weekly health check runs it. If the health check passes, you know the pipeline is actually executing your tests. If it fails, you know something is wrong.
For lint rules: Add a known-bad file that should trigger the rule. Commit a file with a deliberate violation, and assert the linter fails on it. Run this as part of your CI so the linter is verified on every push, not just when you remember to test it.
For AI evals: This is the most important one. You need two controls: a negative control (a known-bad input the grader must reject) and a zero-case guard. Write an assertion like "the dataset must contain at least 100 rows" before running your eval. If the dataset is empty, the suite should fail loudly, not silently report a perfect score.
The Trade-Off
Yes, this is extra work. You're building tests for your tests, monitoring for your monitors. But the cost is minuscule compared to the cost of a silent failure. A single missed production bug from a broken guardrail can cost you a week of debugging and a reputation hit. Four small additions to each guardrail take an afternoon.
Why This Matters More Now
We're increasingly delegating correctness to AI systems. The guardrails we put around them—prompt injection filters, output validators, safety classifiers—are themselves fallible. The article's point about prompt injection defense being "mostly theater" is a perfect example: a keyword blacklist looks like a guardrail, but it's actually just a scarecrow. If you don't test it with a real attack, you don't know it works.
And as we ship more agent-based systems, the guardrails become the only thing standing between a model and production. A model that writes code can be audited by a human—but a model that writes code and executes it autonomously needs guardrails that are actually alive. The stakes are higher, so the guardrails have to be better.
So here's the takeaway: stop trusting green checks. Add a heartbeat. Make your guardrails prove they're alive, or they'll prove it when you're not looking.
Key Takeaways
- A guardrail that has never fired and one that silently stopped running produce the same green output.
- Every check is a monitoring system; it needs a heartbeat to prove it's alive.
- Give each guardrail a known-bad input (canary) it must reject, and record when it last rejected something.
- Assert on run counts so zero-case failures are loud, not silent.
- Attach provenance (harness version, dataset hash, prompt revision) to every eval result.
- Invest an afternoon in this now; the cost of a silent guardrail failure is far higher.