ĀML™ / ĀRU INTELLIGENCE
ENGINEERING EVIDENCE / RECEIPT BINDING

The receipt said A.The callback saw B.

A changing JavaScript getter exposed a real mismatch in the reference action boundary: it hashed the proposal for the receipt, then read the caller's object again before dispatch. The host callback received different bytes. The corrected boundary validates and dispatches one canonical snapshot.

2 → 1Proposal accessor reads before and after the fix
2 / 2Allow and approval-required paths now bind receipt to callback
10 / 10Selected source changes exposed across three finite suites
PINNED REGRESSION / CURRENT REFERENCE

Compare the exact bytes.

The left side reintroduces the second read through one exact source mutation. The right side runs the current boundary. Select the policy path to see both recorded outcomes.

ONE CHANGING GETTER / TWO POLICY MODES

Loading…

REINTRODUCED TWO-READ REGRESSION

Receipt split.

Planning hashes the first value. The second snapshot goes to the callback.

  • CALLER GETTER
  • CALLBACK BODY
  • RECEIPT SHA-256
  • CALLBACK SHA-256
  • APPROVAL FIXTURE
Inspect raw regression result
CURRENT SINGLE-SNAPSHOT BOUNDARY

Receipt bound.

Validation, policy, approval, receipt, and callback use the same frozen proposal.

  • CALLER GETTER
  • CALLBACK BODY
  • RECEIPT SHA-256
  • CALLBACK SHA-256
  • APPROVAL FIXTURE
Inspect raw current result

Loading the checked-in reports…

Mutation report ↗
THE IMPLEMENTATION CHANGE

Freeze once. Trust those bytes.

The proposal is serialized once, and the serialized value is validated. Planning and every later host step use that frozen value. A receipt is now tied to the bytes supplied to the local callback, even when the caller exposes a changing property.

Inspect the boundary source ↗

01 / CANONICALIZERead the caller object once
02 / VALIDATE + PLANCheck the serialized proposal and host rule
03 / HOST PATHBind approval, receipt, and callback to frozen bytes

What was checked?

The Node fixture uses one changing getter in both an allow rule and an approval-required rule. A source substitution restores the second read and reruns all three finite suites. It changes both snapshot cases but none of the 384 static dispatch vectors or eight static tuple cases. A separately coded Python oracle checks the current snapshot report, its source digest, callback payload digest, and receipt relationship.

Run node pilots/action-boundary/snapshot-proof.mjs --check, python3 pilots/action-boundary/verify_snapshot_proof.py docs/action-snapshot-proof.json, and node pilots/action-boundary/dispatch-mutants.mjs --check. Read the reproduction method ↗

Scope: Project-authored in-memory fixtures and selected mutations. The approval hook is a fixture, not a person. There is no provider effect, real delivery, arbitrary JavaScript object coverage, outside witness, or formal proof of production safety. This page presents checked-in observations; it does not independently verify provenance.