Agent procurement examples

Coding job example Original scheduling example

Preparing the example and checking retained storage…

[data-demo-loading] { display: none !important; }

Coding example: three fixes, different next steps

Interactive prototype. Fixed sample code, fictional suppliers, and simulated spending. No AI requests or payments. The accepted total fix makes three $20 items total $60. A second patch incorrectly permits a quantity of −1 and is rejected. Shipping has no confirmed delivery. A replacement coordinator retains the first fix, may purchase a valid quantity fix, and keeps the shipping reservation held. After that replacement, two fixes are accepted: $65 charged, $15 reserved, $20 available under the simulated $100 ceiling. Shipping remains unfinished. JavaScript is required to select and run an example. The original scheduling example is described separately below.

Review this job outside the browser

Browser and local review use the same project-authored implementation. The report reconstructs your saved job; it is not independent replication or an installed Bulla capability.

Order: Run the interactive example to create an order

Save both files at the same checkpoint. Do not advance the job between saves.
JavaScript is required to run the example and save files. If you already have both exports, continue below.
Download the coding review packet. Extract it into a new folder and place both saved files at its root. Requires Node 22.14 or later; tested on Ubuntu and macOS arm64. No Bulla installation or repository checkout.

From that folder, run:

node --experimental-strip-types papers/coding-job-review-001/review.mjs CODE-JOB-RUN.json --context CODE-JOB-CONTEXT.json --out review-001

Open review-001/report.html. Check its order identifier against your export. The adjacent report.json contains the same reconstruction. Use a new output folder for each review.

What remains unresolved?

An unconfirmed shipping attempt stays held. Successful review does not confirm delivery, release a reservation, or establish an enforceable supplier claim. A historical discrepancy or incomplete evidence remains visible and returns a nonzero exit status.

The buyer can keep accepted work without purchasing it again. For a supplier, changing the buyer’s coordinator does not settle a disputed delivery or decide an entitlement. The supplied account alone establishes neither payment nor a right to a remedy.

Unsigned records do not prove authentic or complete history. Only fixed sample modules execute; submitted source remains evidence. The report makes no network request or purchase and does not claim OS-enforced confinement.

Report what happened on GitHub →Packet inventory →

GitHub issues are public. Inspect your report before sharing; no private records are sent automatically.

The broader program: witnessing, dispute review, and backing →

Original scheduling example: local review and historical evidence

The Python reviewer and reports in this section support the scheduling example only—not the coding job. Open the original scheduling example.

Review this order locally

A separate Python implementation reconstructs delivery checks, charges, held reservations, and the next actions permitted by the original demo rules. It makes no purchases.

Read a supplied example

In this supplied example, the coordinator has been replaced: accepted work stays accepted, one rejected item may be replaced, and an unconfirmed attempt stays held. It is not a review of your current run.

Read the supplied review Report JSON

Other supplied examples

Review your exported run

Requires macOS arm64 and Python 3.11.

Use both Save buttons above at the same checkpoint. CONTEXT.json fixes the order requirements, limits, and review checkpoint. RUN.json contains the commands and supplied evidence.
Download the Python reviewer and instructions. Extract it into a new folder and open its papers/order-review-001 directory in a terminal. Place your two exported files in that directory—not in its supplied examples folder.
Create the fresh environment below. Setup downloads hash-pinned dependencies; reviewing the files then runs with network access denied.

bash

python3.11 -m venv .venv
.venv/bin/python -m pip uninstall -y setuptools
.venv/bin/python -m pip install --only-binary=:all: --require-hashes -r requirements-macos-arm64-py311.txt

Uninstalling setuptools removes its automatic startup hook from this fresh environment only, not from your system. See the included README for the confinement boundary.

Then review the two files you saved:

bash

.venv/bin/python -I -B review_order.py RUN.json --context CONTEXT.json --out review-001

Open review-001/report.html and check its order identifier against your export. report.json contains the same result. Choose an output folder that does not already exist, and use a new name for each review.

Both implementations are project-authored and share scheduling and receipt-checking components. Agreement across these implementations is not independent replication or organizational interoperability. Neither supplied file establishes trusted authority; matching accounts do not prove authentic history, payment, or a right to a remedy.

Reviewer source and report inventory

[data-independent-suppliers-demo] { display: none !important; }

One order across separate fictional suppliers

Your coordinating agent applies the customer's requirements. Lead supplies one schedule and, when permitted, subcontracts to North and West. These suppliers represent separate fictional businesses. JavaScript is needed for the local workers and saved-run replay. In the mixed example, one delivery is accepted, one rejected, and one unconfirmed. A replacement coordinator preserves the accepted work and holds the unconfirmed attempt. At a $1.00 ceiling it may replace the rejected item: $0.65 charged, $0.15 reserved, $0.20 available. At $0.60 the replacement is blocked: $0.35 charged, $0.15 reserved, $0.10 available. No payments occur. Read the closed-order assessment below.

Customer-controlled orders

The goal is to let customers use services from different businesses without making one coordinating platform the only place that understands their orders.

Bulla supplies ActionReceipt tools. This experimental application uses retained records and buyer-defined rules to reconstruct purchasing decisions. Checking a receipt’s integrity is a separate operation.

The broader program: witnessing, dispute review, and backing →

Run and inspect the prototype

Run the same coordinator controller from the command line. No provider account or network connection is needed. The supplied schedules are a checkable example workload, not a claim that inference is the best way to solve scheduling.

Download source and instructions Artifact inventory Use the released Bulla tools →

What remains unfinished in our live run?

A new, unexecuted assessment of the earlier Together / Fireworks order preserves 1 accepted item and identifies 11 outstanding items. The order is closed, its original deadline has passed, and no new purchase is authorized. 0 items are currently eligible for dispatch.

Recorded positions in the closed twelve-item order
Items	Assessment
S01	Recorded acceptance preserved; no repeat needed.
S02	Two attempts used; replacement remains unresolved.
S03–S12	Unfinished and unattempted; not a provider failure.

The recorded $0.75 reservation is not a confirmed charge. Unused allowance does not authorize resuming the order. These are historical observations, separate from the constructed demo above.

Read all twelve item assessments →Assessment JSON and sources

Supporting evidence: the earlier Together / Fireworks run was partial

This historical run is separate from the constructed mixed order above. It made 3 real requests: 1 fulfilled item, 11 outstanding, and no completed live process replacement.

One Together output was accepted. Another returned the wrong output structure. A Fireworks response could not be admitted by the capture parser and remains wholly excluded. Its absence is not proof of a supplier breach. Execution stopped with unresolved work.

Matched signed JSON produced the same substantive decisions: 4,068 record bytes, compared with 14,328 for ActionReceipts. The controller and durable custody supplied continuity behavior; receipt format alone did not.

The commercial hypothesis is managed procurement and completion coordination under buyer-controlled rules. These demonstrations do not establish demand, savings, a moat or an advantage over an equivalent custom implementation.

Read the unchanged historical report →

Publication root: sha256:5d714969b29ff0b60aab55b08d107f0b30e426b460761e2e3239fcf4d120d0de