Bulla · Open source

Receipts for agents.

When one agent asks another to deploy code, buy compute, or move money, the provider can say it succeeded. Bulla creates a transaction record the counterparty can keep: the exact request, accepted permissions and limits, returned result, and evidence supplied.

Your application checks that receipt against its own policy before it acts.

Try the evidence check Install Bulla Read the ActionReceipt format

Open format · Local verification · Counterparty-held record

One agent hands work to another

The agent’s claim is not the decision.

CHECKED SYNTHETIC TRANSACTIONEVIDENCE MISSING

A deploy agent says the requested build is ready in staging. The release agent has one additional requirement before production promotion can become eligible.

Deploy-agent claim: Staging ready
Requested build: Matches
Staging-controller observation: Present
Rollback-test result: Missing
Release-agent decision: Wait for evidence
Next required record: Signed rollback-test result
Production promotion: Not eligible
Authorization: Not issued
Promotion attempt: Not attempted

The receipt preserves the staging claim. The release agent waits because the required rollback-test record is absent.

Eligibility is not authorization. This demonstration does not deploy anything.

Technical evidence

decision: HOLD_FOR_EVIDENCE
eligibility: INELIGIBLE
authorization: NOT_ISSUED
execution: NOT_ATTEMPTED

The browser renders a projection generated by the project-authored Python evaluator. It does not run the evaluator in the browser or establish that the deployment claim is true.

Limits of this demonstration

This checks the receipt file. Evidence from the systems that performed or observed the action is still needed to establish what happened.
This synthetic demonstration evaluates retained records under one project-authored policy. It does not deploy anything or establish that the agent's claim is true.

Technical evidence

Verification establishes only the reported digest, identity, or inclusion depth; it does not establish the truth of the underlying process.
The profile, transaction, roles, keys, records, evaluator, and formal model are project-authored. A conditional evidence request does not establish that the requested test exists, will pass, or guarantees promotion. The result does not establish deployment occurrence, worldly truth, receiver-record completeness, legal enforceability, production use, organizational independence, or external implementation parity.

One transaction can span three records.

Keep the provider logs. Bulla standardizes the transaction record that crosses systems, while the customer keeps its own account of received actions.

Provider log: What the provider’s system observed while operating the service.
ActionReceipt: The standard transaction file handed to and retained by the counterparty.
Customer action log: What the receiving application observed independently.

Provider logs can supply evidence to an ActionReceipt. Neither kind of record is assumed to contain every relevant event.

Create the record once. Let each receiver decide.

01CreateEmit an ActionReceipt where your application accepts or completes an external action.
02CheckRecompute the saved record locally instead of depending on the provider to remain available.
03DecideApply your own evidence and authority requirements before the next consequential action.
04ReconcileCompare the receipt set with your action log to identify actions with no receipt.

Built for actions that cross systems.

The model does not need to produce JSON or know that Bulla is present. The gateway, tool router, payment handler, or agent runtime creates the receipt where the action is accepted or performed.

Tool calls and data changesRetain the authorized action, declared limits, reported result, and supplied evidence.Agent-to-agent servicesBind discovery, accepted terms, delivery, and evidence into a transaction another machine can inspect later.Payments and permission changesGive the counterparty a standard record for acceptance, review, and disputes.

Agent-to-agent market examples are source-only experimental proofs, not a live marketplace.

Customers and marketplaces can require receipt support before routing work or accepting delivery. Providers can emit the file from an existing gateway without changing the model.

Start with one action.

Bulla runs locally on Python 3.10+. The fixed demo creates one receipt and compares it with a customer action log containing a second charge.

Open the quickstart →View on GitHub ↗

$ python -m pip install "bulla==0.47.1"
$ bulla demo

constructed local result

receipt emitted       pay_demo_042
receipt integrity     VERIFIED
customer log actions  2
matching receipts     1
missing receipt       pay_demo_043

About the published package

The command shown here comes from the package published on PyPI, not from unreleased repository code.

Technical evidence

Commands labelled published are captured from the exact artifact accepted by PyPI; repository source is not substituted for it.

The format is open. The tooling runs locally.

ActionReceipt is a versioned format with public examples and test vectors. Bulla is its open-source Python toolkit. Glyph Standard maintains the specification and conformance materials.

Read the specification →Check product status Inspect the evidence About Glyph Standard

The browser and packaged checker agree on the published examples.

Limits of the supplied checks

The browser and packaged checker agree on the published examples. That does not show how a separate implementation or live system will behave.

Technical evidence

Passing the supplied vectors establishes fixture parity, not independent implementation or live-system correctness.