I had an ingestion app that published a snapshot for consumption. The dashboard was green, everything looked fine, but something felt off: the data volume wasn't growing as it should. I checked. Serving had been down for 14.71 days, and the alarm had stayed green the entire time. The freshness check had a 26-hour SLA and was being rearmed every 19 minutes by the very publish that wasn't publishing anything.
The ETL trigger fired normally. At load time, it failed. Dagster's Asset Check rearmed anyway, because the monitoring signal came from the same path that was broken. For the alarm to fire, 82 consecutive cycles without rearm would be needed; impossible by construction. No amount of bad luck would make that alarm ring. And the underlying defect is worse than silence: the failure the watcher should report was the same thing that kept it quiet, which inverts the instrument's function; the worse the system state, the stronger the health signal.
If I have a gate that guarantees the quality of my projects and, upon identifying an app with VETO or BUGS, blocks the commit when it doesn't pass CI, that gate needs to effectively be a protective barrier.
If, on the other hand, it's possible to exclude a prefix, a rule, or any other point to bypass it, the problem isn't simply that the bypass exists. The exclusion pushes the obligation to guarantee quality onto each route inside that scope, without that responsibility having been explicitly decided or assumed. That's where the same error occurs: the gate keeps reporting “passed,” but “passed” starts meaning different things depending on where the commit landed. Anyone looking at the result can't distinguish between “verified and approved” and “out of scope.” The exclusion, therefore, doesn't turn the gate off; it makes the gate say “approved” about something it never looked at.
If a code change is made, with a new implementation, but the CI/CD verification is prevented from running due to limitations imposed by the Git provider (for example, the limit allowed by GitHub Actions, or any other platform restriction mechanism), you cannot consider that quality validation happened. The absence of that verification compromises the integrity guarantee, especially when CI/CD is responsible for controlling the quantity or size of a file and ensuring that, if that measurement is exceeded after a change, the application isn't compromised and the change is atomically blocked. The job didn't fail. It didn't happen. And not having happened is indistinguishable from having passed for anyone looking later.
There is a complex case, similar to one in a novel where an industrialist outsources the decision about protecting his most precious asset: a metal that took ten years to develop. By delegating that choice to an operator in Washington, he lets someone outside his domain determine the fate of what took a decade to build, paving the way for the project's ruin.
The point is not just having delegated. It's having taken that operator's approval as if it were the verification itself. Without checking the result, he received the external decision with the sense of duty done that only direct examination would give. The stamp took the place of proof. It's the same green as the other cases, only generated by a person instead of a machine: judgment was displaced and treated as if the fact had already been proven. The form changed, not the error: taking as verified what was never verified.
The strongest objection to all of this is another one.
The cost of verifying is real and immediate; the cost of not verifying is hypothetical and deferred. In most systems, absence of verification and successful verification produce exactly the same result; and do so for years. If the false green dashboard caused no concrete loss, the problem isn't the false positive: it's you demanding rigor where criticality doesn't justify it. Verification without proportion to consequence is ceremony, not engineering.
Indeed, not every system needs a check, and it's fine to remove what isn't justified. But there is a fundamental difference between a system that is actually working, a system that has no verification mechanism at all, and a system that produces a signal that it's working when, in reality, it isn't.
In the first case, you have traceability, security, and monitoring: if something happens, there is evidence that the system was being verified and mechanisms to identify the problem and restore the application quickly. In the second, you simply don't know. It may be working or not, but there is no mechanism to determine that. The third is the worst case: there is something attesting that it's working, you believe that signal and, precisely because you believe it, you stop noticing the problem that's happening. It's like having a knife stuck in your back without feeling pain: you don't know there's a problem, but it's still there.
That's why Quality Assurance comes in as a reconciliation mechanism: it's not enough to verify continuously; you need to verify that the verification itself keeps working. The previous verification needs to be confronted with real evidence that what it should detect can still be detected.
That's where the data ingestion app becomes relevant. If a vendor delivered a system whose health signal was produced by the very process it should audit, would you accept that system as reliable?
And yet, that is exactly what happened in my own system: the dashboard stayed green for days, and I kept looking at it as evidence that everything was working. The problem wasn't just the absence of a verification; it was believing in a verification that had never been reconciled with reality.
