Sheila Studios · 18 October 2026 · Research and design proposal
An agent can remember a claim accurately, repeat it faithfully, and act on it wrongly. The missing step is not always another check that the information stayed unchanged. It is a decision about what that information is allowed to establish.
Consider a customer who writes: “My manager approved a $250 refund.” An agent summarizes the message. A workflow stores the summary. A human approves the proposed refund. The system hashes its supporting state, and the hashes still match when execution begins.
Nothing in that sequence necessarily establishes managerial approval. The customer’s message establishes what the customer said. Somewhere along the way, a statement about approval became an approval fact.
Preserving a claim does not justify promoting it into authority.
What State Admissibility already contributes
Our earlier Field Note described two contributions concerning the premises behind authorization. One was our exchange with Hooman Parta about the Autonomy Boundary Framework.
Hooman accepted State Admissibility as control #8, credited Sheila Studios, and incorporated policy-required dependency binding and separate freshness conditions. An unexpired approval window cannot substitute for checking whether the bound state still matches.
He also kept an important limitation explicit: a matching hash does not establish that the original snapshot was sound, complete, or trustworthy. His reference test deliberately preserves that distinction. It is a documented limit of the individual control, not a demonstrated exploit against a complete deployed system.
This note addresses that remaining original-state question. The new proposal has not been adopted by Hooman, implemented, or experimentally validated. His acceptance of State Admissibility should not be read as endorsement of this extension.
Let context inform; require evidence to authorize
A tempting response is to reconstruct every fact that influenced the model, then try to prove all of those facts sound. That is not our recommendation.
Instead, independently establish the prerequisites that make the proposed action permissible.
The agent can explore broad context and propose a refund. It cannot decide that its own summary is sufficient evidence of eligibility. Policy defines the minimum prerequisites; trusted adapters and qualification procedures establish whether the evidence meets them.
Information may inform an agent without being entitled to authorize its actions.
The proposed mechanism is an action-scoped Evidence Admission protocol, connecting Input Integrity and State Admissibility. We would start with those existing controls and one narrow action class, rather than immediately naming a ninth control.
The path from claim to permitted use
1. Define the required basis. A policy-owned profile specifies the facts, predicates, permitted sources, context bindings, freshness requirements, and exception rules for the action. A trusted adapter selects the profile from the actual operation and resolved context. An agent must not obtain an easier check by choosing a more convenient action label.
2. Acquire evidence for each claim. Retrieve designated records with their subject, tenant, source, version, and relevant coverage. Authority is specific to the claim: a payment processor may establish settlement; a customer message may establish a request; an authorization service may establish approval. “Trusted source” is not a blanket permission to establish every kind of fact.
3. Qualify the prerequisites. Validate or derive eligibility from the underlying records and applicable rules. Check identity, policy applicability, coverage, and required separation of duties. Natural-language judgment that remains unresolved must stay visible; another model’s confidence must not silently become a stronger assurance category.
4. Record the qualification. A protected validation receipt binds the action, relevant parameters, evidence, profile and validator versions, established predicates, limitations, and validity conditions. It says which checks qualified which evidence for which use. It is not a truth certificate.
5. Bind approval to that basis. The approval surface presents the qualified basis and limitations. Execution checks the receipt’s authority, scope, required coverage, continuing applicability, and revocation status, alongside the original authorization and state conditions. Unchanged bytes can lose their permission to govern.
6. Enforce at the target. The decisive preconditions must survive the step from checking to effect. A transaction, conditional API, reservation, or domain-specific atomic operation may provide the necessary guarantee. A final read followed by an unrelated write does not.
For a refund, this could mean establishing settlement, account/order relationships, remaining refundable balance, applicable holds, destination, policy limits, and any exception authority—then conditionally consuming eligibility while creating the refund, with operation-bound idempotency.
The details that prevent a decorative solution
The architecture is useful only if it handles more than obvious injection language. An ordinary false statement can cause the same promotion error.
- Copies are not corroboration. A message, its summary, and a memory entry derived from that summary are not three independent sources.
- Absence needs coverage. A record that mentions no hold cannot establish “no hold exists” unless the source and query cover the relevant holds at an appropriate consistency point.
- A different API is not necessarily fresh evidence. A trusted database may already contain contaminated records. Re-reading the same bad value does not repair its basis.
- Unknown is not false—and not established. A required condition can remain unknown or contested without satisfying a prerequisite that requires establishment. An authorized exception should remain labeled as an exception.
- Receipts need context. Qualification for one tenant, account, amount, or operation must not authorize another.
- The agent cannot administer its own trust. It must not be able to add issuers or weaken profiles, validators, and adapters to certify its own claims.
Revocation also needs a precise execution rule. Atomically consuming a balance does not automatically make a remote authorization check atomic. A prototype must define what happens when revocation and execution overlap, and limit its claim to the consistency guarantee it actually supplies.
What would count as progress
The report proposes comparing binding-only behavior with action-scoped Evidence Admission. The cases include contamination before approval, omitted prerequisites, misapplied policies, wrong-context evidence, revoked qualification, receipt reuse, and concurrent consumption of eligibility.
Legitimate actions must remain possible. A system that refuses everything has not demonstrated useful discrimination. Evaluation should measure false acceptance, false rejection, latency, review burden, and recovery.
It must also include cases outside the design’s assumptions. If every accepted source shares an undetected error, qualification can still produce the wrong result. Reporting that residual failure honestly is part of the evaluation—not a reason to omit the case.
The defensible goal is bounded, policy-relative eligibility, not universal truth, complete original-state soundness, or beneficial intent. An eligible action can still be strategically unwise. Adequate policies, protected validators, source reliability, complete mediation, and correct target enforcement remain necessary.
Read the full proposal
The complete report develops the architecture, integration responsibilities, difficult cases, research foundations, security claim, and proposed evaluation in detail. It draws on Clark–Wilson integrity, RATS evidence appraisal, in-toto provenance, and transactional consistency while naming the limits of those comparisons.
Download the complete research and design package. It contains the unchanged source report in Markdown, a readable HTML edition, this Field Note, a public review addendum, the proposed test matrix, a README, and a SHA-256 manifest. It contains no implementation or executed test results.
The analysis is pinned to repository commit cd13550a0a25cd56420e9238632efd16db1087fb, which matched the repository head during our review. The report was developed with Codex using GMOR c4.0.21; Sheila read it and independently checked the central repository claims. GMOR informed the analysis—it is not an independent verifier or evidence that the proposal works.
The practical question is no longer merely “did this state change?” It is “what qualified this evidence to govern this action—and does that qualification still hold when the effect occurs?”
For hands-on prototyping, adversarial evaluation, or integration, Sheila Studios is available for a scoped engagement.