Imagine a bouncer at a nightclub. The bouncer checks your ID — that's the policy engine. But checking your ID doesn't verify you paid the cover charge, that you're not on a ban list maintained by a different venue, that your wristband matches tonight's event, or that the fire marshal's capacity limit hasn't been hit. The bouncer's 'you're 21' decision is correct, but it's not an admission decision. This paper names and formalizes that gap for software systems. The committed claim: policy engines like OPA (Open Policy Agent) and Cedar answer a narrow question — does this request satisfy the stated policy? — but the industry treats that answer as an execution-admission judgment. It isn't. Between 'policy says ALLOW' and 'safe to execute,' there's an uncollapsed space of governance-source completeness, context binding, and trust verification that no existing engine explicitly contracts for. The authors introduce the Binding-Complete Execution Admission Contract (BCEAC) to make that space falsifiable. The architecture is layered and deliberately engine-agnostic. Governance resolution, policy evaluation, independent admission verification, and downstream execution mediation are separated into distinct phases. Participating backends must satisfy declared semantic profiles and adapter contracts. An optional Execution Boundary Language (EBL) provides authoring syntax, but the core contribution is the contract structure, not a new language. Think of it as an interface specification for what must be proven true between the policy decision and the execution gate. The experimental evidence is narrow and honest about it. Two tracks: a finite Governance Source Completeness study and an OPA/Cedar experiment comprising 72 scenarios and 144 strict case-engine records (120 native-invoked, 24 pre-native), plus 8 permissive controls outside the strict denominator. Critically, the offline review did not rerun the original OPA/Cedar executables — it examined archived records. The authors are unusually forthcoming about what this does NOT establish: no constitutional adequacy, no general semantic refinement, no machine-checked safety theorems, no authenticated currentness guarantees. The ladder position is awkward because there's no direct competitor framework to benchmark against. The paper is not claiming better performance on a shared metric — it's claiming a new category of contract that doesn't exist yet. This makes it simultaneously important (if the gap is real, someone needs to name it) and hard to evaluate (without adoption, the framework is untested at scale). The closest prior art is the implicit trust model baked into OPA and Cedar themselves, which the paper argues is underspecified. The integrity picture is mixed. The authors are admirably transparent about retained historical failures and unresolved implementation defects in the archive. But the validation is self-graded: no independent team has run the BCEAC framework against production workloads, and the OPA/Cedar experiment is archival review, not live execution. The 74-page length reflects thoroughness but also a framework paper's tendency to define terms rather than prove theorems. What matters here is whether the security and authorization community picks up this vocabulary. If BCEAC becomes a checklist that teams use to audit the gap between their policy engine output and their actual execution gates, this paper will have contributed something lasting. If it remains a 74-page definitional exercise, it's an interesting footnote. The honest answer is that the concept is clearly needed — anyone who has debugged a production authorization failure knows the gap exists — but the evidence base is pre-adoption, and the real test is whether practitioners find the framework useful enough to implement.
