A Waived Gate Is a Failed Gate

Everyone publishes what worked. This publishes what broke, and the rule it became.

I found a dangerous sentence inside an otherwise practical delivery escape hatch: “>=95 or three attempts then proceed.” It was meant to prevent one stubborn gate from deadlocking the whole pipeline. In practice, it turned a FAIL into a phase-clear.

The next reader saw “done.” The system had actually said “not done, but allowed through.” Those are different facts.

A waiver is a decision to continue. It is not evidence that the gate passed.

The escape hatch became a lie

The factory gate had a threshold for auto-proceeding. The exact shape was simple: a high enough score, or three failed attempts, and the phase could continue. That mechanism solved a real operational problem. Pipelines can deadlock. People need a way to make a deliberate decision and keep moving.

The failure was not the existence of the escape hatch. The failure was the output shape. The waived result was recorded like a real pass. Downstream reports could not distinguish “the evidence satisfied the gate” from “someone accepted the risk of proceeding despite the evidence.”

That is failure laundering. The system did not remove the failed evidence; it removed the label that made the evidence useful.

That is why the result needs to remain machine-readable. A human may remember that a waiver happened; a later process needs a field it can count, filter, and display. The safe default is conservative: if the record says waived, the report carries the failure forward.

The rule became explicit

The lesson that came out of it is deliberately blunt: a waived gate is a FAIL and is never recorded as PASS. Continuing is allowed only if the record keeps the failure, the waiver, and the reason together.

The gate reader now looks for explicit bypass signals in the evidence packet. It checks boolean flags such as waived, overridden, and skipped, as well as verdict strings such as WAIVED, OVERRIDE, and SKIPPED. It returns a separate waiver list instead of silently adding those rows to the pass count.

That implementation detail matters. A report can now answer two questions separately: did the gate pass, and did the run continue under a waiver? The first remains false. The second has a reason attached.

Authority has a paper trail

There is another layer for a hard BLOCK. The final-authority invariant says the agent cannot reason around an enforce-mode block or reframe it as a recommendation. The literal token OVERRIDE_BLOCK is required to bypass it.

The token is intentionally awkward. It prevents a vague “continue” from being mistaken for an explicit human decision. When used, the system moves the active block record to an overridden record and writes a decision file containing the violations, the verbatim prompt, a timestamp, the project, and the task identifier.

The file is not bureaucracy for its own sake. It is the answer to a later question: what did we knowingly bypass, who asked for it, and what did the system know at the time?

The same discipline applies to human approvals. A reviewer should be able to see the original verdict, the bypass signal, and the reason without reconstructing a conversation from memory.

What I check now

I read the gate result before I read the celebratory summary. I look for a pass verdict, then I look for waiver fields. I make sure skipped rules are not being confused with waivers: a rule can be inapplicable because the profile says it does not apply, while a waiver means a gate did apply and was bypassed.

I also inspect the reason. A waiver without a reason is just a second, less honest spelling of pass. If the pipeline cannot say what was accepted and why, it has not created an escape hatch; it has created a blind spot.

The lesson is now high-severity in the factory ledger, and its enforcement hook is the done gate itself. That is the right home for it. A documentation promise cannot repair a result schema that collapses two states.

The operating rule

I want autonomous systems to keep moving, but I do not want them to rewrite history in order to do it. The safe pattern is: keep the gate failure, record the waiver as a failure with a reason, require an explicit override for a hard block, and write the decision to a durable file.

That gives the operator speed without giving the dashboard permission to lie.

If you run agents, do this

• Keep PASS, FAIL, and WAIVED as distinct states.
• Never add waived results to the pass count.
• Capture a reason beside every waiver.
• Require an explicit token for a hard-block override.
• Write the violations, prompt, timestamp, project, and task identifier to a decision file.