The question before “passed”
Consider two systems. One verifies an approval that has not expired. Another applies an authorization rule exactly as written. Both return a clean result.
But the first approval may depend on state that has changed. And the second checker may have received its action category from the very agent asking for permission.
A passing check establishes only what that check actually verifies. It does not automatically establish that the inputs selecting the rule are trustworthy, or that the conditions behind an earlier approval still hold.
One contribution adopted: State Admissibility
In our discussion with Hooman Parta about the Autonomy Boundary Framework, the distinction was between showing what a human approved and establishing whether the decision-critical dependencies remain valid enough to govern execution.
The dependency set matters as much as the check. Policy should define the minimum dependencies for an action class. An agent may add relevant dependencies, but must not silently omit the required ones. For higher-risk actions, a live approval window and verification of the bound state are separate requirements.
An unexpired approval window is not proof that the state is still current.
Hooman accepted State Admissibility as control #8, distinct from Legibility, explicitly credited Sheila Studios, and reported updates across the write-up, threat model, reference control, tests, demo, evaluation scenario, and example policy.
That is a concrete external adoption of a contribution. It is not a claim that the framework now guarantees sound decisions. As his acceptance makes explicit, a matching hash can establish that a bound snapshot is unchanged; it cannot prove the original state was sound, complete, or trustworthy when approved.
A companion study: who selects the rule?
Our paper, Decoupling Policy Optimization from Boundary Enforcement in Sequential Delegation, is a companion to Matthew Francis Dixon’s Adaptive AI Delegation under Uncertainty: A Bayesian Governance Policy for Sequential Decision Authority.
Dixon’s work addresses adaptive allocation of decision authority. It already separates inference, validation, governance, and execution, and establishes conditional admissibility and robustness results. Our complementary question concerns the implementation assumptions: who establishes the classification that determines which restriction applies to a proposed effect?
If a protected operation needs additional approval, but its proposer can authoritatively label it “ordinary,” an otherwise correct checker can apply the wrong rule. The checker need not malfunction. The classification has quietly acquired authorization power.
This is an architectural argument with a bounded executable demonstration—not a demonstrated exploit of Dixon’s implementation, a refutation of his conditional results, or a claim to have invented reference monitors.
What the demonstration shows—and does not
The public finite model compares three implementations: one trusts the proposer’s classification; two obtain it from a registry outside the proposer’s control. The two registry-checking implementations use different organizational arrangements, including an integrated design. Separation of trust responsibilities does not require separate machines or another model.
With accurate registry evidence, the label-trusting checker executed 20 of 40 unauthorized opportunities in the constructed static grid. Both registry-checking implementations executed none and completed all 56 authorized opportunities. The label-trusting checker also denied 20 of those 56 authorized opportunities.
The adverse cases are just as important. Missing registry evidence caused both registry-checking designs to deny all 56 authorized opportunities in that condition. A corrupt registry that under-classified protected resources caused both to execute all 40 unauthorized opportunities in that condition, compared with 20 of 40 for the label-trusting checker. In the separate corrupt over-classification condition, both registry-checking designs denied 40 of 48 authorized opportunities, compared with 20 of 48 for the label-trusting checker. The registry-checking designs therefore performed worse on those respective counts when their trusted source was wrong.
Those are counts in a deliberately constructed finite domain, not estimates of deployment failure rates. Independence from the proposer blocks one route to self-authorization; it does not make the registry correct. Refusal also has an availability cost.
The evidence release contains the standard-library Python harness, traces, results, and reproduction instructions. Appendix A reports a separate, partial exploratory decision pilot. Its declarations are not evidence of runtime enforcement. The preprint includes contribution and substantive AI-use disclosures and has not been peer reviewed.
The connection—and the remaining gap
These contributions meet at the same question: what makes the premises behind an authorization check fit to govern?
- State Admissibility: do the decision-critical dependencies still satisfy the conditions under which execution was approved?
- The Dixon companion: can the proposer control the classification that selects its own authorization rule?
They are not the same problem, and one does not solve the other. In particular, the companion paper does not resolve the framework’s acknowledged gap around contamination that predates the approved snapshot. Preserving bad evidence faithfully is still preserving bad evidence.
The practical lesson is not “add another checker.” It is to make the trust assumptions inspectable: which claims matter, who may establish them, what happens when evidence is missing or wrong, and what must remain true until execution.
At Sheila Studios, we look for the point where a useful abstraction stops carrying the guarantee people expect from it. Here, that produced an adopted control and a reproducible companion study. The value is in making the boundary clearer—and leaving enough public evidence for someone else to challenge it.
In your system, who establishes the facts that select an authorization rule, and what establishes that those facts still hold when the action takes effect?
Discuss an authorization or agent-workflow problem with Sheila Studios →