Original-state soundness in the Autonomy Boundary Framework

Date: October 18, 2026
Status: Research and design proposal only; no implementation or executed validation.
Repository reviewed: hoomanp/autonomy-boundary
Review commit: cd13550a0a25cd56420e9238632efd16db1087fb

Executive finding

There is a practical way to address a substantial part of the remaining gap: require evidence-based qualification of decision-critical state before that state can authorize an action.

The important qualification is that this would establish bounded, policy-relative admissibility, not universal factual truth.

James and Sheila’s distinction is the right foundation:

State can be unchanged without ever having been qualified to govern the action.

The proposed extension is therefore not another hash, another approval, or another model judging whether the first model seems correct. It is an enforceable separation between:

• Information the agent may encounter and reason about.
• Claims supported by evidence acceptable for a particular purpose.
• Claims permitted to satisfy the prerequisites of a particular action.

My recommendation is to develop this as an Evidence Admission protocol connecting Input Integrity and State Admissibility, initially for one narrow action class. I would not immediately introduce a ninth control.

This report addresses the original-state soundness limitation in §5 associated with issue #1, not every remaining edge listed in that section.

1. Review scope and evidence

I used the full local GMOR c4.0.21 runtime as the requested reasoning scaffold. That supports the structure of this analysis; it is not an independent verifier or evidence that the proposed controls work.

I inspected:

• The current threat model.
• The complete issue #1 comment discussion.
• The reference implementation’s intent representation, Input Integrity control, State Admissibility control, boundary execution flow, specification, and State Admissibility tests.
• Relevant primary material on integrity models, evidence appraisal, provenance, and transactional consistency.

The repository findings below are pinned to commit:

cd13550a0a25cd56420e9238632efd16db1087fb

I did not execute tests, implement changes, or post anything to GitHub. Proposed tests and security properties below are recommendations, not demonstrated results.

2. What James and Sheila’s contribution established—and what Hooman implemented

Sheila’s comment separates three questions that are easily conflated:

1. Is this the action that was approved?
2. Are its decision-critical dependencies still the same?
3. Were those dependencies sound enough to govern the action in the first place?

She also identified two essential restrictions: policy must determine the minimum dependency set, and a validity window cannot substitute for checking current state. Sheila’s comment

Hooman’s response explicitly accepts State Admissibility as control #8, credits Sheila Studios, and says the implementation now includes mandatory dependency binding and both freshness conditions for high-risk actions. He also preserves the original-state limitation rather than claiming the new binding solves it. Hooman’s acceptance

That is a substantive improvement, with an appropriately honest boundary.

The next step should preserve that honesty: strengthen what the framework can establish without relabeling cryptographic continuity as semantic correctness.

3. What the current code actually establishes

3.1 State Admissibility checks continuity, not qualification

The reference control checks required dependency names, supplied current hashes, and applicable validity-window conditions. It does not establish the business validity of the values represented by those hashes. The current-state mapping also comes from the caller; trustworthy acquisition of that mapping is therefore a deployment responsibility, not something this control independently performs. State Admissibility implementation

That is not merely an interpretation of the documentation. One test deliberately constructs:

{"account_status": "injected", "refund_policy": "v3"}

It supplies matching hashes at approval and checking time, then asserts that this individual control allows the state. The test intentionally documents the limitation. It is not evidence that a complete deployed boundary necessarily permits a real poisoned refund. Reference test

3.2 Input Integrity provides a useful extension point

The default Input Integrity implementation screens parameter and target strings for several suspicious patterns. It also supports custom validators, which could implement substantially stronger checks.

Consequently, the framework already has an integration point. What is missing from the inspected default implementation is a mandatory, action-specific contract for qualifying the underlying evidence—not the ability to add validation code. Input Integrity implementation

3.3 Checking and effect are separate operations

The boundary evaluates an intent, then invokes the action callback. That generic sequence does not itself make the eligibility check and target-system effect atomic. A production adapter must provide the necessary transaction, conditional operation, reservation, or equivalent guarantee. Boundary execution implementation

This matters because improving original-state validation still leaves a race if the relevant state changes between validation and effect.

4. The remaining failure mechanism

Consider this hypothetical sequence:

1. A customer-controlled document claims that a manager approved a refund.
2. The agent incorporates that claim into a summary.
3. A later process treats the summary as an established account fact.
4. The approval surface presents a refund based on that fact.
5. The relevant snapshot is hashed.
6. Nothing changes before execution.

The system can correctly establish that the approved action and its bound state remained unchanged.

It has not established that the customer-controlled statement was entitled to establish managerial approval.

The failure is a change in evidentiary status:

An external party made a claim
             ↓
The agent repeated or summarized it
             ↓
The system treated it as an authoritative premise
             ↓
That premise satisfied an action prerequisite

Hashing the final premise preserves the result of that promotion. It does not justify the promotion.

This can occur without obvious injection language. An ordinary-looking false statement may be enough.

5. The essential distinctions

A defensible design must keep these properties separate:

The key relationship is:

Authentic evidence is not automatically authoritative evidence; authoritative evidence is not automatically sufficient evidence.

A customer email may be sufficient to establish that a request was made. It is not sufficient to establish that the requested action was approved.

6. Proposed architecture: action-scoped Evidence Admission

The governing rule would be:

An agent may propose an action using arbitrary context, but it may not satisfy the action’s eligibility conditions using arbitrary context.

The architecture needs six connected elements.

6.1 Policy-owned admissibility profiles

Each protected action class needs a profile defining:

• Required facts and predicates.
• Permitted sources for each fact.
• Required validation procedures.
• Subject, tenant, principal, and target bindings.
• Applicable policy version and selection rules.
• Freshness and revocation requirements.
• Conditions requiring escalation or refusal.
• Execution preconditions that the target must enforce.

For example, a refund profile might require:

• A settled payment.
• A matching order and customer relationship.
• Sufficient remaining refundable balance.
• No applicable hold.
• A permitted destination.
• An amount within the applicable policy.
• Separate authority for any exception.

This is more than declaring that account_status and refund_policy must be present.

The profile must say what those dependencies must establish.

The agent must not be able to choose an easier profile by changing an action label. Profile selection must be bound to the actual operation and its resolved context.

Similarly, a valid policy document is insufficient if it is the wrong policy for the customer, jurisdiction, product, or effective date.

6.2 Independently acquired evidence

For protected prerequisites, a trusted adapter should retrieve evidence from designated sources rather than accepting the agent’s description of those sources.

The adapter should preserve:

• Source and record identity.
• Record version.
• Relevant subject and tenant.
• Observation or effective time.
• Schema and interpretation version.
• The specific claims the source is permitted to support.

The source must be evaluated per claim, not merely marked “trusted.”

For example:

• A payment processor can establish settlement status.
• A customer message can establish the content of a customer request.
• An authorization service can establish an applicable approval.
• An agent-generated summary establishes none of those facts by itself.

This does not mean all direct database reads are trustworthy. A database can already contain contaminated records. That harder case requires controlled write paths, reconciliation, or independent evidence—not simply reading the same bad value through a different API.

6.3 Controlled qualification and derivation

Evidence should become action-governing state only through an explicit qualification procedure.

Possible checks include:

• Schema, type, range, currency, and unit validation.
• Identity and tenant matching.
• Authorized state-transition checks.
• Reconciliation between records.
• Policy applicability.
• Required separation of duties.
• Contradiction checks over a defined evidence set.
• Coverage checks for required prerequisites.

Derived claims require particular care.

If the agent says:

“The customer is eligible for a $250 refund.”

The system should not accept that sentence as the eligibility fact. It should compute or verify eligibility from the underlying records and applicable rule.

For natural-language conditions that cannot be reliably reduced to deterministic checks, the profile must explicitly identify the remaining judgment requirement. A model’s interpretation may assist that judgment; it should not silently become a stronger assurance category.

6.4 Action-scoped validation receipts

Successful qualification can produce a signed or otherwise protected validation receipt.

Such a receipt should bind:

• The action class and relevant action parameters.
• The subjects, tenant, principal, and target.
• The admissibility profile and validator versions.
• The evidence records and their versions or digests.
• The predicates established.
• The coverage achieved.
• Outstanding limitations.
• Freshness and revocation conditions.
• The qualified issuer.

This should be called a validation receipt, not a truth certificate.

Its meaning is:

These specified checks, under this specified policy, qualified this evidence for this specified use.

It must not mean:

This state is objectively true in every relevant respect.

Receipts must also resist cross-context reuse. A valid receipt for one account, tenant, amount, or operation must not authorize another.

6.5 Bind approval and execution to the qualification

Qualification should occur before approval so that the approval surface can show the actual basis and limitations of the proposed action.

The final approved intent should bind the relevant evidence and qualification artifacts.

At execution, the boundary must check that:

• The receipt is authentic and from an authorized issuer.
• The receipt applies to this action.
• Required coverage is present.
• The applicable policy remains valid.
• The qualification has not expired or been revoked.
• The relevant state still satisfies its required conditions.
• The original action authorization remains valid.

This adds a distinction missing from a pure hash comparison:

The underlying bytes may be unchanged while their permission to govern execution has been revoked.

A changed policy, withdrawn approval, or invalidated evidence source can make a previously qualified snapshot inadmissible without changing the snapshot itself.

6.6 Enforce preconditions at the effect boundary

Where possible, the target operation should enforce the decisive predicates atomically.

For a refund, this could mean an operation that conditionally consumes the remaining refundable balance while creating the refund, with an idempotency mechanism tied to the operation identity.

Suitable mechanisms depend on the target:

• Database transactions.
• Compare-and-swap or version preconditions.
• Conditional APIs.
• Reservations.
• Single-use capabilities.
• Domain-specific atomic operations.

A final read followed by an unrelated write is not equivalent.

Where the target cannot supply the needed guarantee, the system must disclose that limitation and use an explicitly authorized alternative: a smaller operation, a reversible workflow, manual handling, or refusal. It should not claim the race has been eliminated.

7. Why this does not require reconstructing all model reasoning

A tempting but impractical approach would be:

Discover every fact that influenced the model, then prove all of them sound.

That is not the recommended design.

Instead:

Independently establish the prerequisites that make the proposed action permissible.

The model may use broad context to generate proposals. It does not get to define the complete set of checks required to authorize them.

This avoids relying on a model’s self-report of what influenced its decision.

There is an important limit: an action can satisfy every declared prerequisite and still be strategically unwise, manipulative, or contrary to an incompletely specified objective. Evidence Admission does not replace adequate scope, budgets, composition controls, or policy design.

It establishes bounded eligibility—not beneficial intent.

8. Handling the difficult cases

Contamination predates the first snapshot

For new records, enforce qualification at entry and preserve subsequent authorized transformations.

For existing records, do not retroactively declare the entire store trustworthy. Qualify the needed facts through reconciliation or fresh evidence. Records without a defensible basis remain unqualified for protected use.

The “authoritative” source is wrong

A signature proves who asserted something, not whether the assertion matches reality.

Higher-assurance profiles may require independent reconciliation, separation of duties, or external confirmation. But if every accepted source shares the same underlying error, the system can still be wrong.

That residual assumption must remain explicit.

Three sources repeat one false statement

Three copies are not three independent confirmations.

The evidence model should preserve common origin where known and prevent a summary, a memory entry, and a retrieved copy of that summary from being counted as independent corroboration.

Complete detection of hidden common origins is not generally guaranteed.

The agent rewrites a claim into a trusted-looking record

Rewording, copying, summarizing, or persisting a statement must not improve its evidentiary status.

However, propagation labels alone are insufficient. A stronger safeguard is that the qualification service derives or checks protected predicates from designated evidence rather than trusting the agent’s rewritten assertion.

The required fact is a negative

“No hold exists” or “no previous refund exists” needs more than a document that happens not to mention a hold or refund.

The evidence must come from a source with defined coverage, queried at an appropriate consistency point. Otherwise the result is “not established,” not “absent.”

A required condition is unknown or contested

Keep distinct statuses:

• Established.
• Refuted.
• Unknown.
• Contested.
• Expired or revoked.

An unknown condition is not necessarily false. Nevertheless, it cannot satisfy a prerequisite requiring establishment.

An authorized exception should remain visibly an exception. It should not rewrite uncertainty as validated fact.

9. Research foundations

This proposal is not a claim that a new cryptographic primitive is needed. Several established ideas provide useful foundations.

Clark–Wilson: controlled transitions into protected state

The Clark–Wilson integrity model distinguishes unconstrained input from constrained data and restricts how transformations move information into the protected domain. Its treatment of external consistency and separation of duties is especially relevant: internally consistent records can still misrepresent the world.

The useful adaptation is to make promotion from “observed claim” to “action-governing state” a controlled transformation. Application-specific validation remains essential. Original Clark–Wilson paper

IETF RATS: evidence is appraised before reliance

RATS separates evidence, verifier appraisal, and the relying party’s decision. This supports the proposed distinction between a source assertion, a validation result, and permission to use that result.

The analogy has limits: attestation of a computing environment does not establish the truth of business facts processed by that environment. Appraisal policies and trust anchors themselves also need protection. RFC 9334

in-toto: provenance requires explicit coverage

in-toto provides useful concepts for authorized steps, artifact relationships, and verification rules. Its documentation also makes an important limitation clear: recording explicitly supplied artifacts does not automatically capture every relevant input.

For this proposal, a provenance graph is useful only alongside a policy-defined coverage requirement. A perfectly authenticated incomplete graph can still omit the decisive dependency. in-toto documentation

Transaction isolation: validation must survive concurrency

Serializable transactions illustrate how concurrent operations can be constrained to outcomes equivalent to a serial ordering. They do not establish business truth, and they do not automatically encompass effects in unrelated external services.

The relevant lesson is to enforce the declared business predicates within an appropriate atomic boundary rather than treating a prior read as a lasting guarantee. PostgreSQL transaction isolation documentation

10. What would need to change in ABF

I would begin with a narrow extension rather than a broad rewrite.

The existing custom-validator interface may support part of this without a new control class. The exact API design should follow a small prototype and threat review.

Two implementation constraints are particularly important:

The agent must not control the trust configuration. It cannot be allowed to add an issuer, weaken a profile, modify a validator, or change an adapter and thereby certify its own claim.

Evidence gathering and boundary checking have different costs. Upstream acquisition and appraisal can be expensive. Checking a well-scoped receipt can be cheaper. Neither the latency nor the safety of that separation should be assumed without measurement; caching requires a defensible freshness and revocation policy.

11. Tests that would distinguish a real mitigation

These are proposed tests—not tests I ran.

The evaluation should measure false acceptance, false rejection, latency, review burden, and operational recovery—not just whether contrived attacks are denied.

The strongest demonstration would compare:

1. Existing binding-only behavior.
2. The same behavior with action-scoped Evidence Admission.
3. Deliberate cases beyond the new design’s assumptions.

That third category is necessary to prevent a misleading “gap closed” conclusion.

12. Defensible security claim

I would not claim:

The approved state is guaranteed complete, uncontaminated, and true.

I would propose a narrower statement:

For registered action classes, execution requires every policy-mandated prerequisite to be supported by currently applicable, authorized evidence qualification bound to the action and its context. Protected effects also enforce the declared execution preconditions. Information lacking that qualification cannot satisfy those prerequisites.

That claim still depends on:

• Correct and sufficiently complete profiles.
• Protected validators and trust configuration.
• Acceptable source reliability.
• Correct action and context binding.
• Complete mediation of relevant effects.
• Target enforcement of required atomic conditions.

These are named engineering and governance assumptions, not reasons to abandon the design.

13. Recommendation to Hooman

I would frame the next contribution this way:

State binding protects continuity after approval. The remaining addressable gap is qualification before approval: what permits a dependency to govern the action at all? An action-scoped Evidence Admission protocol could require policy-defined predicates, permitted evidence sources, validated derivations, explicit coverage, and revocable receipts bound to the action. State Admissibility would then check both continuity and continued qualification. This would not prove universal original-state soundness, but it would prevent specified classes of unsupported or misapplied evidence from becoming executable authority.

Start with one bounded action, such as the refund example, and demonstrate the difference between:

• An unchanged assertion of eligibility.
• Eligibility independently established under the applicable policy.
• Eligibility still enforceable at the moment of effect.

Bottom line

Yes—the seam can be addressed meaningfully, but not by making the hash carry a claim it cannot support.

James and Sheila’s contribution exposed the distinction between preserving state and justifying its use. The next architectural step is to make that justification an explicit, constrained, independently checked admission process.

The most important principle is:

Information may inform an agent without being entitled to authorize its actions.