Skip to content

A machine buyer, two inference routes.

A replacement buyer process used retained responses and its operator’s requirements to recover past decisions, then continue purchasing schedules through OpenRouter. The acceptance code stayed unchanged.

Recorded research experiment · synthetic scheduling problems

24 requests · 11 usable · 12 rejected · 1 unresolved

Real inference, local schedule checks and simulation. OpenRouter supplied the common routing interface. This is not a decentralized marketplace or a released buyer runtime.

Review a purchase from retained evidence

A later inspection of purchase P05 compared the retained response with a deliberately omitted response, using the same original buyer requirements and observer records.

Purchase P05 · recorded inspection under the original buyer’s requirements
CheckResponse retainedControlled omissionResponse deliberately omitted
Earlier buyer decisionUsableUsable
Local observer’s signatureChecks successfullyChecks successfully
Reproduced delivery checkMeets the original scheduling requirementsUnresolved: response absent

The signed record still shows what the buyer accepted. This inspector requires the original response to check the delivery again; the earlier assessment is not a substitute.

P05 · controlled omission

P06 supplies the cross-route example under the same requirements: read the P06 report, download its JSON, or inspect the case archive.

Source, checking context, and reproduction

Locally tested on macOS arm64/Python 3.11. An outside-developer walkthrough has not yet been completed.

Both signed representations reproduced the same substantive checks. These local tests used one physical machine, not an independent implementation. The signatures authenticate a local observer, not the inference provider. Neither the historical assessment nor its reproduction determines the recipient’s acceptance, breach, refund entitlement, or legal authority.

The source archive contains the research tool and its frozen checker modules. It is not a supported Bulla installation or a new package release. The source notes explain setup with hash-pinned dependencies on macOS arm64/Python 3.11. After setup, case inspection runs without network access.

Tool code, case evidence, and checking context are separate downloads. Downloading this example context does not independently establish trust in its key or make its requirements the visitor's policy. The context specifies the original buyer’s requirements, observer key, and checker identity.

All 23 purchases with public responses passed local reproduction. P01 remains excluded. The original corpus is unchanged; these handoff artifacts have their own closed inventory. Review references describe project-operated technical review, not outside-developer participation.

This handoff supplies evidence for later review. Witnessing, authorized adjudication, and financial backing perform additional functions; they are not features of this candidate.

Handoff publication root: sha256:89b334db04a53d3f0367061a5104d1945a2748d60294030a9fd11e7bd1f6353e

Deliveries

Each problem specified 8 jobs, 3 machines and a horizon of 32 time units. The buyer checked completeness, machine eligibility, release times, deadlines, precedence and non-overlap. A feasible schedule could be used; it did not have to be optimal.

Both requested routes advertised meta-llama/llama-3.3-70b-instruct. Purchases alternated which route went first. Each request was distinct; errors were not retried. Provider and model names are service-reported routing information, not authenticated evidence of upstream execution.

All 24 requests through OpenRouter. Phase 2 begins at P13.
Purchase / problemRequested routeBuyer decisionReasonRecord
P01 / S01deepinfra/turboUnresolvedHTTP error; no delivery decisionJSON
P02 / S01akashml/fp8UsableFeasible schedule; local simulation authorizedJSON
P03 / S02akashml/fp8RejectedJobs overlap on a machineJSON
P04 / S02deepinfra/turboUsableFeasible schedule; local simulation authorizedJSON
P05 / S03deepinfra/turboUsableFeasible schedule; local simulation authorizedJSON
P06 / S03akashml/fp8UsableFeasible schedule; local simulation authorizedJSON
P07 / S04akashml/fp8UsableFeasible schedule; local simulation authorizedJSON
P08 / S04deepinfra/turboRejectedOutput does not match the required schedule structureJSON
P09 / S05deepinfra/turboRejectedOutput does not match the required schedule structureJSON
P10 / S05akashml/fp8RejectedJobs overlap on a machineJSON
P11 / S06akashml/fp8RejectedA timing requirement was not metJSON
P12 / S06deepinfra/turboRejectedOutput does not match the required schedule structureJSON
P13 / S07deepinfra/turboRejectedOutput does not match the required schedule structureJSON
P14 / S07akashml/fp8UsableFeasible schedule; local simulation authorizedJSON
P15 / S08akashml/fp8RejectedJobs overlap on a machineJSON
P16 / S08deepinfra/turboUsableFeasible schedule; local simulation authorizedJSON
P17 / S09deepinfra/turboUsableFeasible schedule; local simulation authorizedJSON
P18 / S09akashml/fp8UsableFeasible schedule; local simulation authorizedJSON
P19 / S10akashml/fp8UsableFeasible schedule; local simulation authorizedJSON
P20 / S10deepinfra/turboRejectedOutput does not match the required schedule structureJSON
P21 / S11deepinfra/turboRejectedOutput does not match the required schedule structureJSON
P22 / S11akashml/fp8RejectedJobs overlap on a machineJSON
P23 / S12akashml/fp8UsableFeasible schedule; local simulation authorizedJSON
P24 / S12deepinfra/turboRejectedOutput does not match the required schedule structureJSON

P05 · Usable

deepinfra/turbo · problem S03 · via OpenRouter

P05 and P06 answered the same problem through different requested routes. The buyer admitted the schedule for local simulation, using the same checker.

Installed requirements digest
sha256:12164a6a8094ddb5e06521339eb357f0fa8887114baee1d69c80cf93c1308eb8
Retained assessment
sha256:29bb862e7d4c55bd115179892b9848744886e4b9e55ad0b7a890a0b5f6483da8
Returned schedule · P05Time units 0–8
  • J1, machine M3, starts at 0, finishes at 3.
  • J2, machine M1, starts at 0, finishes at 1.
  • J3, machine M2, starts at 1, finishes at 4.
  • J4, machine M3, starts at 3, finishes at 4.
  • J5, machine M1, starts at 1, finishes at 4.
  • J6, machine M2, starts at 4, finishes at 5.
  • J7, machine M3, starts at 5, finishes at 8.
  • J8, machine M1, starts at 4, finishes at 5.

P06 · Usable

akashml/fp8 · problem S03 · via OpenRouter

The other route returned another feasible schedule under the same requirements. The buyer admitted the schedule for local simulation, using the same checker.

Installed requirements digest
sha256:12164a6a8094ddb5e06521339eb357f0fa8887114baee1d69c80cf93c1308eb8
Retained assessment
sha256:381614c5726a5a31587a3b794f9d7bf3161673b388429443d770edbdd8afd527
Returned schedule · P06Time units 0–8
  • J1, machine M3, starts at 0, finishes at 3.
  • J2, machine M1, starts at 0, finishes at 1.
  • J3, machine M2, starts at 1, finishes at 4.
  • J4, machine M3, starts at 3, finishes at 4.
  • J5, machine M1, starts at 1, finishes at 4.
  • J6, machine M2, starts at 4, finishes at 5.
  • J7, machine M3, starts at 5, finishes at 8.
  • J8, machine M2, starts at 5, finishes at 6.

P03 · Rejected

akashml/fp8 · problem S02 · via OpenRouter

The returned assignments overlapped on a machine. The buyer rejected this delivery and issued no consumption instruction.

Installed requirements digest
sha256:adf1580cd6b4cb5ef0c588bb139796ef36cb14fe1324a5780aa856a7f23acf83
Retained assessment
sha256:0e20be750a0f29f4d28ef651fd5edea3933e412f6076323c6573a4d51875f3e2

Returned content · rejected for overlap

{"assignments": [
{"job": "J1", "machine": "M2", "start": 0},
{"job": "J2", "machine": "M3", "start": 0},
{"job": "J3", "machine": "M1", "start": 0},
{"job": "J4", "machine": "M2", "start": 2},
{"job": "J5", "machine": "M3", "start": 4},
{"job": "J6", "machine": "M3", "start": 6},
{"job": "J7", "machine": "M2", "start": 6},
{"job": "J8", "machine": "M3", "start": 8}
]}

Process continuity

The first buyer process completed 12 purchases and stopped. A fresh process recovered its durable state and completed the remaining 12. It did not ask the supplier to resend earlier responses.

  1. Live phase 1

    2026-09-05T03:49:50Z to 2026-09-05T03:51:26Z

    Source sha256:4c02691a151cc96d1e22219b656086cbbfbc13f78910bf98ed1f1255f8cf02cc

  2. Live phase 2

    2026-09-05T04:36:14Z to 2026-09-05T04:37:29Z

    Source sha256:4c02691a151cc96d1e22219b656086cbbfbc13f78910bf98ed1f1255f8cf02cc

The following 6 tests were injected afterward using the sealed P02 response, with network access denied. They are controlled buyer-process failures, not live provider outages.

Injected tests, separate from the live restart
Crash locationRecovery resultAfter repeat recovery
before dispatchNo dispatched purchase0 local consumptions
after intentUncertain dispatch; no automatic retry0 local consumptions
after captureStored assessment recovered1 local consumptions
after assessmentStored assessment recovered1 local consumptions
before consumptionStored assessment recovered1 local consumptions
after consumptionStored assessment recovered1 local consumptions

The simulator recorded 11 unique consumptions in the live batch and 0 duplicates. Its dispatch keys make repeated local application idempotent. That does not establish exactly-once external execution or payment.

Evidence retained

When response payloads were removed during replay, every purchase became unresolved under both signed representations. A commitment identifies bytes; it cannot reconstruct a missing schedule.

Retained evidenceUsableRejectedUnresolved
Original captures (private P01 included)11121
Response payloads absent0024

The public corpus includes 143 exact members and reproduces 23 original decisions. P01’s entire account-bearing error response remains private. Its existing exclusion notice is published, with no redacted substitute. Public replay leaves P01 unresolved because its payload is absent; reproducing the original HTTP-error assessment requires the withheld original.

Methods and limits

Ordinary Ed25519-signed JSON and ActionReceipt carried the same local-observer statements and produced the same decisions. The measured format overhead is reported below; the experiment did not measure integration effort or an interoperability advantage.

RepresentationObservation record bytesSignature checksPython SHA-256 input bytes
Signed JSON17,13624147,969
ActionReceipt v0.458,41672402,417

Counts cover adapter/evaluation work, not native signature-internal hashing or total storage cost. The same retained payloads and buyer logic served both formats.

OpenRouter
Supplied the common interface and requested provider routing. A routing-parameter change is not evidence that Bulla reduced integration work.
Buyer controller and custody
Supplied the scheduler checks, durable decisions and recovery. These are research-harness capabilities, not features supplied by the Bulla package.
Local simulator
Consumed accepted schedules once per dispatch key. No physical jobs were scheduled and no settlement was executed.
Bulla
Created portable ActionReceipts. Signatures authenticated the local observer’s statements, not OpenRouter, its providers or historical model execution.

Inference charges followed OpenRouter’s service rules even when the buyer rejected an answer. The known service-reported cost sums to USD 0.00288350, with 1 unresolved charge; it is not a verified total bill. This small sample does not support a provider-performance ranking.

The result does not establish market demand, independent buyer adoption, provider authentication, direct-provider interoperability, payment, legal recourse or operation without a common router. As of the recorded study, existing x402 signed offers and receipts and payment identifiers addressed adjacent payment and retry concerns. Neither x402 nor a decentralized marketplace was implemented or comparatively tested here.

Downloads and reproduction

Download the frozen source and evidence to inspect the measurements or replay the public decisions. No API key or additional inference request is needed. Local reproduction was validated on macOS arm64 with Python 3.11; portability remains untested.

  1. Check the archive against its detached SHA-256, then extract it. The source inventory binds each file to the frozen experiment commit.
  2. Create a fresh Python 3.11 environment and install the hash-pinned requirements. The Bulla wheel hash and dependency identities are in DEPENDENCIES.json.
  3. From the extracted directory, run the network-denied public replay. Never run the capture command: the recorded batch is complete.
python3.11 -m venv .venv
.venv/bin/python -m pip install --require-hashes -r requirements-macos-arm64-py311.txt
.venv/bin/python -I -B analysis/replay_safe.py evidence /absolute/new/safe-replay.json

The replay path must not already exist. It reproduces the public decisions without credentials and cannot reconstruct P01. Expected replay results are in SAFE-REPLAY.json.

Historical records retain their original local-only authorization and status text. This publication does not rewrite that completed experiment or promote its controller into a product. The reviews are project-operated model reviews, not independent human adoption evidence.

Frozen experiment commit
1e0a8d6f8a00faca3a0f9245868a50bb52ffe56f
Exact public corpus root
sha256:8f9a69df24a8c8e32e4bfca0e5be6c3255a2bcb3ec254202addd40154d75e4cd
Buyer source root, unchanged across processes
sha256:4c02691a151cc96d1e22219b656086cbbfbc13f78910bf98ed1f1255f8cf02cc
Use the released Bulla toolkit