Of 3,222 Decision Receipts in production, 43 were blocked and 1 was escalated. These 44 non-accepted receipts are not failures — they are the proof that the system's 99% acceptance rate is earned. A deny-by-default policy that never denies is a rubber stamp. This episode traces what triggered each block, follows the escalated receipt from ambiguity to resolution, and argues that 99% acceptance is more meaningful than 100%.
By the end of this episode, you will understand what triggers a block in a deny-by-default AI governance system, why the single escalated Decision Receipt is the most architecturally significant artifact in the entire system, and why a 99% acceptance rate proves more than 100% ever could.
| Claim | Risk | Status | Evidence |
|---|---|---|---|
| Of 3,222 Decision Receipts in production, 43 were blocked and 1 was escalated — these 44 non-accepted receipts are the proof that the system's acceptance rate is earned, not assumed. | low | approved | 1 |
| The Decision Receipt system operates on deny-by-default: every commit must affirmatively pass all policy checks to receive an ACCEPTED receipt, inverting the traditional CI/CD model where everything passes unless a specific check fails. | medium | approved | 1 |
| The 43 blocked receipts fall into five operational categories — policy violation, missing provenance, scope violation, configuration drift, and safety boundary — and are distributed across multiple agents, proving uniform enforcement. | medium | approved | 2 |
| The single escalated receipt involved a cross-scope commit touching both patent-sensitive and public files, and the system's response — surfacing uncertainty as a first-class event rather than guessing — demonstrates a defined boundary of autonomous authority. | medium | approved | 1 |
| A 100% acceptance rate would indicate either a rubber-stamp policy engine or selection bias toward trivial changes; a 99% rate with 43 documented blocks proves the system has operational teeth and every acceptance is meaningful because rejection was possible. | low | approved | 2 |
Forty-three. That's how many times the Decision Receipt system looked at a commit and said no. And one. That's how many times it looked at a commit and said: I don't know — you decide. Out of 3,222 total receipts, these 44 are the ones that matter most. Not because they failed. Because they prove the other 3,178 earned their acceptance.
To understand why blocks matter, you need to understand how the system works. Most CI/CD pipelines operate on allow-by-default. Your commit goes through, unless a specific check catches a specific problem. If no check fires, you pass. Silence is consent. The Decision Receipt system inverts this completely. It operates on deny-by-default. Every commit starts in a denied state. It must affirmatively pass every policy check to receive an accepted receipt. Silence is denial.
This is not a philosophical distinction. It's an operational one. In an allow-by-default system, a new policy rule only catches violations if someone writes a check for it. In deny-by-default, a new policy rule immediately applies because the default is no. An unknown commit type? Denied. An unclassified change? Denied. The burden of proof is on the commit to demonstrate compliance, not on the system to demonstrate a violation.
So what actually triggers a block? We see five categories in production. First: policy violation — the commit content matched a restricted pattern, like patent-sensitive material appearing in a public-facing file. Second: missing provenance — the commit lacked required metadata for evidence chain reconstruction. Third: scope violation — an agent tried to modify files outside its authorized scope.
Fourth: configuration drift — the commit would have introduced configuration that conflicts with declared system state. Fifth: safety boundary — content flagged by safety classifiers as requiring human review. These blocks are distributed across multiple agents. No single agent accounts for a majority. The system enforces uniformly. It doesn't care who you are. It cares what you're committing.
Now the most interesting story in the entire system. The escalated receipt. Out of 3,222 receipts, exactly one was escalated. Not blocked. Not accepted. Escalated. This is a third disposition — it means the policy engine encountered a condition it was not designed to resolve autonomously. It refused to guess. It routed to a human decision-maker. And that refusal to guess is architecturally the most significant thing the system has ever done.
Here's what happened. A commit touched both patent-sensitive restricted files and public-facing documentation in the same change. The policy engine detected the cross-scope modification. It could not determine whether the public-facing changes contained patent-sensitive material derived from the restricted files — that requires semantic understanding beyond pattern matching. So instead of failing open or failing closed, it failed visible. It surfaced the uncertainty as a first-class event, created an escalation receipt, and waited for a human. That human reviewed the commit, confirmed no sensitive material leaked, and the commit was processed. The full chain — ambiguity, escalation, human review, resolution — is preserved in the receipt.
So here's the argument that ties this together. If the acceptance rate were 100%, it would mean one of two things. Either the policy engine is not enforcing any meaningful constraints — it's a rubber stamp. Or the system is only processing pre-approved, trivial changes — selection bias. Neither is accountability. But a 99% rate with 43 documented blocks? That proves the system has teeth. Every accepted receipt is meaningful because rejection was possible. The blocks are the warrant for the acceptances. That's not a bug in the metrics. That's the whole point.
Forty-three blocks. One escalation. 3,178 earned acceptances. The system that says no is the system you can trust when it says yes. Check the source appendix for the full blocked commit analysis and the escalation case study, then visit decrec.summitcognitive.ai to see a system that proves its governance by showing you when it refused to govern alone. This has been Warrant, Season One, Episode Four.