Records used at an agent transaction boundary.
The published package creates and checks ActionReceipts, applies a supplied receiver policy, and reconciles receipts against a separately supplied customer record.
Provider record, ActionReceipt, receiver record
Provider infrastructure keeps the operational records it needs. Application code sends an ActionReceipt across the boundary with one accepted request and reported result. The receiving party keeps that file and compares it with records from its own systems.
Provider record
An internal account of what the provider accepted or reported.
ActionReceipt
The portable transaction record delivered to the receiving party.
Receiver record
The customer-side list of actions used for coverage reconciliation.
None of these records receives a presumption of completeness. A receiving party chooses its verification context and decides which records its policy will consider.
ActionReceipt anatomy
One JSON file records the action, accepted authority and limits, reported result, evidence references, retention terms, and challenge path. Cryptographic commitments let a verifier detect changes to committed fields.
Action and result
Evidence references
Retention, challenge, and remedy
Commitments
Canonicalization and field rules live in the ActionReceipt standard.
Verification depth
Action
one consequential transition
Receipt
authority · bounds · evidence · recourse
Verify
adds · integrity
recompute the record from pinned inputs
Rely
adds · reliance
the policy and its decision, recorded
Witness
adds · retention
the receipt held outside its issuer
Challenge
adds · recourse
the conveyed forum and remedy path
What receipt verification does not establish
This checks the receipt file. Evidence from the systems that performed or observed the action is still needed to establish what happened.
A digest match establishes less than an accepted signature, and an accepted signature establishes less than independently grounded evidence. Bulla reports these dimensions separately under the verification context supplied by the receiver.
Authority and scope
The receipt names the signer, mandate, policy, and bounds presented for the action. Verification checks those fields and any supplied signatures or parent references. The receiver still decides which issuers, keys, and delegations it accepts.
Receiver policy and reliance
Verification produces a report over the supplied records. A separate ReliancePolicy uses that report to return RELY, REFUSE, or ESCALATE. Applications can record that decision as a new consequential action.
The receiver supplies the trust anchors and policy. Bulla does not select them on the provider’s behalf.
Verification and reliance are separate
Decision flow is implemented in Bulla; no live downstream relier operates here.
Coverage reconciliation
Receipt verification starts with the files presented. Coverage starts with a separately supplied receiver record and asks which listed actions have matching receipts. A valid receipt can therefore coexist with an unreceipted action.
Coverage remains relative to that supplied action list. Bulla cannot discover an event absent from both the receipt set and the receiver record.
Challenge and recourse fields
ActionReceipt fields can carry a challenge window, named forum, and ordered remedy terms. Those fields make the procedure portable; operation still depends on the organization or authority named in the record.
A receipt can convey recourse terms without establishing that a forum is reachable or a remedy is enforceable.
Recorded terms do not operate a remedy
A consistently conveyed remedy adapter establishes recourse terms, not that a forum, remedy, or settlement path is operational.
Research concepts moved
Composition diagnostics, witnessing formats, and related experimental vocabulary now live with the broader research architecture. The legacy anchors below remain available for old links.