Require this from an AI vendor.

Six requirements

1. 01Emit one ActionReceipt per consequential action.
2. 02Bind it to the accepted request, authority, and limits.
3. 03Sign it under a key accepted for the transaction.
4. 04Deliver it to the customer for retention.
5. 05Keep it verifiable in the open ActionReceipt format.
6. 06Make verification independent of the vendor service’s continued availability.

Starting procurement language

Copy this into a vendor conversation or procurement draft. It is starting language, not legal advice.

For every consequential action performed on Customer’s behalf, Vendor will deliver one ActionReceipt in the agreed open format. The receipt will bind the action to the accepted request, authority, and limits; identify its evidence references and available challenge fields; and be signed under a key accepted for the transaction. Customer may retain and verify the receipt locally without continued access to Vendor’s service. Receipt verification does not by itself establish server identity, tool execution, result correctness, or complete recording.

Full procurement specification

The sections below separate requirements available with the released Bulla package from optional repository-source research material.

Vendor logs and customer records

Provider logs are useful, and Bulla does not replace them. But those logs usually use the provider’s schema, live in the provider’s account, and cover activity across its system. A customer reviewing one transaction later may depend on the provider’s access controls, export format, and retention policy.

A provider can export the relevant event, bind it to the buyer’s request and accepted terms, authenticate it, and let the buyer retain it. Bulla places that material in a customer-facing transaction record so buyers do not need a new log schema for every provider.

Customer-retained files

An ActionReceipt records one transaction in an open, versioned format. Customers, auditors, claims handlers, and underwriters can check the retained file after an agent or provider endpoint becomes unavailable. Receipt verification alone does not establish occurrence or complete recording.

A constructed USD 125.00 example shows the records used for a payment dispute. Download the retained receipt or run the local checks.

Shipped receipt requirements

ActionReceipts cover the accepted request, authority and limits, reported result, evidence references, challenge fields, local verification, and customer reconciliation.

Checks before accepting delivery

Treat the receipt as an input to customer policy. Before delivery, name acceptable signers, evidence sources, action-log coverage, and challenge terms.

Missing records may justify waiting for more evidence; a verified negative result may justify refusal. An eligible result still requires a separate authority record before any execution attempt.

• Verification-kit archive matches the contracted detached or signed-release digest.
• Retained-receipt drill reports checker agreement and rejects its tamper control.
• Receipt integrity is reported as a named dimension rather than a global status.
• Authority is reported as authenticated, unauthenticated, forged, unresolved, or not applicable.
• Report identifies each evidence item as a provider statement, reproducible computation, counterparty-signed record, or another supported evidence class.
• Coverage report identifies the supplied action log and every unmatched action in it.
• Receipt names the challenge forum, window, remedies, and current reachability status.

Download the verification kit and its detached digest.

Who retains the records

Bulla Labs does not host operational receipt sets. The customer and counterparty retain their own copies under an agreed policy. No independent receipt register is currently operated.

Vendor integration point

Buyers, routers, and marketplaces can make receipt support a condition for routing work or accepting a delivery. A provider that supports the format can participate in those workflows and use the same agreed record for acceptance, audit, and disputes. The model itself does not need to create the receipt; the provider’s gateway or runtime can emit it.

Local receipt and coverage checks

$ bulla receipt verify receipt.json --format json
$ bulla receipt drill receipt.json --format json

from bulla import event_coverage

# Fact-bearing dispatch rows must carry record_sha256, and each delivered
# receipt must bind that digest in its result or evidence references.
report = event_coverage(
    vendor_dispatch_log,
    delivery_receipts,
    anchor="vendor-dispatch-log",
)
print(report["unreceipted_delta"])

Applicable logging duties

EU AI Act requirements include automatic event logging for high-risk AI systems (Article 12) and retention of at least six months (Article 26(6)), with high-risk obligations applying from August 2, 2026. ActionReceipts complement those operational logs with a separate customer-facing transaction record that another party can retain and check. Whether a given deployment is high-risk is a determination for the deployer and its counsel, and this page does not make it.

Implementation work for vendors

Bulla Labs publishes Bulla under the Apache-2.0 license. Providers add Bulla to the gateway, tool router, payment handler, or agent runtime that already accepts and records the action. Customers receive the resulting file and can run local checks without a hosted service.

Send this page to the vendor, then use the quickstart or the Python integration guide.

Optional research material

1. R1

   Named evidence rules and external trust roots

   State which evidence test applies and obtain accepted signer keys, witness roots, and authority grants outside the vendor-supplied dossier.

2. R2

   Challenge process and decision authority

   Define the window, forum, correction path, and exact authority that may decide or authorize a consequence.

3. R3

   Bounded capital and recourse

   Name the maximum covered loss, required allocation, binding mode, permitted remedy, and authority for any attempted transfer.

4. R4

   Portable assurance dossier

   Deliver the promise, relevant receipts, receiver evidence, witness references, challenge state, and any consequence records in a retained package.

1. W1

   Operator and key

   Name the witness operator, log, key identifier, and authority epoch. Obtain the accepted trust roots outside the vendor-supplied dossier.

2. W2

   Checkpoint exchange

   Require signed checkpoints, leaf-bound inclusion, append-only consistency evidence, and a route for exchanging views between relying parties.

3. W3

   Covered fault

   State the exact objective predicate. For the current source profile, coverage is limited to two authentic different roots for the same log, epoch, and tree size.

4. W4

   Challenge and authority

   Name the challenge checkpoint, correction path, settlement authority, permitted destination, and maximum consequence.

5. W5

   Bond allocation and priority

   Name the unit, dedicated or pooled allocation, priority against competing claims, and the external evidence required to accept the reported lock.

6. W6

   Rail evidence

   Name the settlement adapter and distinguish eligibility, authorization, an attempted rail event, execution, and collection.

Review the current witness covenant and its limits before adapting these clauses.

Optional research rider

Where the parties adopt an answerability profile, they will also name the evidence rule, external trust roots, witness operator, checkpoint exchange, challenge procedure, decision authority, capital allocation, permitted consequence, destination, and settlement adapter. No financial consequence may be attempted unless the supplied dossier establishes the agreed predicate, coverage, challenge, authority, and capital conditions. Semantic or appraisal disputes will be routed to the named forum.