How ActionReceipts fit into an agent transaction.
Provider logs describe one system. An ActionReceipt gives the counterparty a standard transaction record to keep. A receiver log records what the next system observed.
One transaction, three records
An agent calls a provider, tool, or another agent. The provider may write an internal log. The application handling the transaction creates an ActionReceipt for the counterparty. The receiving system may keep its own action log. These records answer different questions, and Bulla does not assume that any one of them is complete.
01
Provider log
What the provider recorded inside its own system.
02
ActionReceipt
The portable transaction record sent to the counterparty.
03
Receiver log
What the receiving system observed independently.
Why not use the provider’s logs?
Provider logs are useful, and Bulla does not replace them. If a provider exports the relevant event, binds it to the buyer’s request and accepted terms, authenticates it, and lets the buyer keep it, that export can become evidence for an ActionReceipt. Bulla standardizes the customer-facing transaction record so every buyer does not need a custom integration for every provider’s logs.
| Question | Provider log | ActionReceipt |
|---|---|---|
| Primary use | Operate and debug the provider | Hand one transaction to the counterparty |
| Custody | Usually controlled by the provider | Retained by each receiving party |
| Format | Provider-specific | Open and versioned |
| Scope | A stream of system activity | One action or transaction |
| Checks | Whatever the provider exposes | Local checks defined by the format |
| Completeness | Not assumed | Not assumed |
The model does not need to create the file. An API gateway, tool router, payment handler, or agent runtime can emit it when accepting or completing an external action.
ActionReceipt anatomy
An ActionReceipt is a standard JSON file for one transaction. Its main fields answer practical questions about the action, the authority and limits accepted for it, the evidence supplied, and the available challenge path. Its commitments let another party detect later changes to the file.
actionWhat consequential transition is recorded?
mandate.authorityWho permitted it, under which policy?
mandate.boundsWhat did that permission allow?
evidence_refsWhat evidence supports the record, and how is it grounded?
remedyWhere does a challenge go, and what remedies are named?
hashesCan the content, occurrence, attestation, and log leaf be recomputed?
See the ActionReceipt standard for canonicalization, preimages, conventions, and verification levels.
Answerability flow
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 this check cannot tell you
This checks the receipt file. Evidence from the systems that performed or observed the action is still needed to establish what happened.
Technical evidence
Verification establishes only the reported digest, identity, or inclusion depth; it does not establish the truth of the underlying process.
What Bulla can check
Bulla checks each claim at the depth supported by the supplied record and external verification context. It keeps file integrity, signer authority, evidence, reliance policy, and challenge terms separate rather than collapsing them into one verdict.
Reliance
bulla.rely receipt records the receipt being relied on, the selected policy, the claimed decision, and the recomputed result. Reliance becomes an explicit consequential act of its own.Verification reports the receipt dimensions. A supplied relying-party policy computes the separate RELY, REFUSE, or ESCALATE decision.
What this check cannot tell you
The three-exit reliance decision and its receipt are implemented in the Bulla library and exercised by library vectors; no live downstream relier operates on this site.
Recourse
Registry and inclusion
WitnessReceipt and ActionReceipt
Signed deed
Disposition
Experimental composition diagnostics
The composition plane finds conventions that a tool graph needs but its observable schemas do not disclose. It localizes the seam and can apply a scoped bridge or translation.
disclosure_deficit = rank(delta_full) - rank(delta_observable)What this check cannot tell you
The coherence fee measures undisclosed conventions in a pinned composition model; it is not Bulla's safety foundation or an execution-failure predictor.
Composition diagnosis
Coherence fee / disclosure deficit
Blind spot
Semantic dimension
Interaction score
Convention pack
Standards and restricted registries
Bridge and translation
What still depends on another record or institution
Record and process
Verification tests the receipt. Stronger evidence must come from the systems or counterparties that observed the underlying process.
What this check cannot tell you
Witness evidence establishes what entered a witnessed history; it does not prove the underlying execution occurred or reveal omitted actions.
Terms and operation
The receipt carries a challenge route and remedy terms. The named forum remains an operational dependency.
What this check cannot tell you
A consistently conveyed remedy adapter establishes recourse terms, not that a forum, remedy, or settlement path is operational.
Full technical reference
Epistemic receipt
Boundary fee
Contradiction score
Structural diagnostic
Verification bill
Disclosure state
What this check cannot tell you
Exact means minimum-cost within the pinned finite repair model; it is not proof of safe execution or a universal real-world cost.