Receipts for Agents.
Bulla gives the system relying on the work an ActionReceipt it can retain, verify under its own policy, and reconcile against its own records. In Bulla, that system is the receiver.
Bulla 0.49.2 · Python 3.10+ · Apache-2.0
Application code creates the receipt around the consequential call. A model never has to generate the JSON. Receiving systems retain the file and apply their own verification context and policy.
$ python -m pip install "bulla==0.49.2"
$ bulla demo --out first-actionThis local scenario uses wrap_action to emit one receipt, checks a changed copy, and compares the receipt set with two customer-log entries. No payment network is contacted.
$ bulla receipt drill first-action/receipts/pay_demo_042.json --format jsonRun the drill to compare Bulla with the packaged standalone checker while network operations are denied. Output separates checks over saved files from questions that need another source.
Download the retained verification kit or verify a receipt in the browser.
Verification kit details
Keep the archive and detached digest with the receipt set. Its manifest covers every member, and the signed release receipt authenticates the published archive.
Kit SHA-256: 8f2cdd16bcbd1a1121f49545b6a6512872b188221ca30ec054dfd6b2fb2142ab
Create a receipt around the consequential call
from bulla import wrap_action
with wrap_action(
"payments.charge",
{"event_id": "pay-1", "amount_minor": 12500},
) as action:
receiver.charge(amount_minor=12500)
receipt = action.receiptOne transaction, three records
The provider reports the action. An ActionReceipt crosses the boundary. The receiving system compares it with its own record.
Provider record → ActionReceipt → Receiver record
Provider-side log
Internal operational log
Provider systems keep this log for their own operation.
not supplied to this check
Retained boundary artifact
ActionReceipt
- event
- pay_demo_042
- amount
- USD 125.00
- original integrity
- CHECKING
- changed copy
- CHECKING
Customer record
Observed actions
- actions
- —
- matching receipts
- —
- coverage
- CHECKING
Computing receipt integrity and coverage…
Integrity checks the receipt in hand. Reconciliation compares the receipt set with the customer’s supplied action record.
This control changes an amount without recomputing the stored commitments. It does not authenticate the issuer or prove that a payment occurred. Reconciliation can find only actions present in the supplied customer record.
Inspect the receipt computation
- Inputs
- Customer actions
pay_demo_042andpay_demo_043; one receipt forpay_demo_042. - Checks
- Recompute the stored commitments and compare bound action identifiers.
- Result
- Original record integrity
VERIFIEDto digest; coverage1/2; unmatchedpay_demo_043. - Boundary
- An action omitted from both supplied inputs remains invisible.
| Receiver supplies | Bulla computes | Never inferred |
|---|---|---|
| Receipt bytes | Record integrity and declared-convention checks | Worldly truth or occurrence |
| Trusted keys or roots | Supported signature and inclusion checks | Key custody or signer independence |
| Receiver action record | Actions without matching receipts | Completeness of that record |
| Pinned policy, time, and revocation context | RELY, REFUSE, or ESCALATE | Policy suitability, custody, or settlement |
Four tasks
- 01CreateEmit a portable transaction record where an application accepts or completes an external action.
- 02CheckRecompute a saved receipt locally without contacting the provider.
- 03DecideApply a supplied receiver policy before another consequential action.
- 04ReconcileCompare a receipt set with customer records and identify actions with no receipt.
What ships where
| Surface | Public state |
|---|---|
| Bulla | Published Python package 0.49.2 |
| ActionReceipt v0.2 | Normative stable format |
| ActionReceipt v0.3 | Non-normative released draft |
| ActionReceipt v0.4 | Opt-in experimental draft |
| Answerability profiles | Repository-source research profiles |