Two marketplaces, one rail

• Intake is standard OTLP. Any component that emits OpenTelemetry log records hands us decisions (ai.decision, subject reference, inputs digest — pseudonymised). API description: apeirora.cotrugli.tech/docs.
• What crosses to the rail is one 32-byte commitment per period, per edge (NEOF1 v0.2, ratified 4 Sep 2026). Records stay in the emitter's own book; the rail never sees a document, an amount or a counterparty. Silence is free: an empty period costs nothing and is still attested.
• A sealed commitment is assigned a public position, witnessed by two independent nodes, and positions are grouped into public units (in the current epoch a unit spans 60 seconds; the tier is named HOUR by a declared, published mapping). The rail has been in its production epoch since 2 September 2026. Reading a receipt by the period commitment alone — no lane token, no operator in the loop — is deployed since 5 September 2026 (ledger route POST /v1/seals/receipt/lookup; MCP tool proof_by_commitment at mcp.cotrugli.tech). What it gives: operator-free reading for whoever holds the commitment. What it does not give: isolation between companies — commitments are deterministic hashes of content.
• Proofs verify offline. A kit of JSON files and a reference verifier recompute record → snapshot → commitment → rail leaf → witnessed position → public unit, using Merkle proofs and a pinned registry of witness public keys. The kit-completeness check: each snapshot names how many records it sealed, and the kit must carry exactly those — a record missing from the kit shows as a gap. It does not prove that nothing was left out before sealing. The verifier is downloadable below and runs on any laptop; it is our reference implementation, not an independent one.

Ariba-shaped buyer (hvar1) · Alibaba-shaped seller (hvar2) · no message between them

A deal is a trading relation named from the contract number alone — both edges derive the same relation_ref without talking — plus the buyer's purchase order in cXML vocabulary on one side and the seller's confirmation in trade-order vocabulary on the other. Each side seals every second: one 32-byte commitment in one frame. The kits carry a deterministic random sample of deals with full proof material; the same deals are sampled on both sides, so a verifier can show the two books agree on the relation and both reach a witnessed position. Deals one side reached in a second the other did not (353 buyer-only, 180 seller-only in the sample) are reported as one-sided, never paired. Verdict PASS, 0 failures — verify_trade.json · summary.json.

Example deal D-p1-1788605447-0-1142: relation 06ced47638e57546… in both books; buyer's commitment 9d83404603592fee… at position 476, seller's c799ac842c2eef7f… at position 476.

One deal, three shapes. What each system hands over, what the edge writes, and what leaves:

Illustrative single-record period built with the same code the kits use (one_deal_three_shapes.json); the run's real commitments are in the kits.

Shapes, not connections: the documents are shaped like those networks' documents so the pairing across marketplaces is real; neither Ariba nor Alibaba is connected. That is the ask for the General Assembly. Live view while a run is on: demo/8ra/live.

An ApeiroRA-shaped placement scheduler, 50 decisions, then the issuer is killed

What happened, act by act (screenplay.log):

1. 21:39:52Z 0-SETUP — issuer up {}
2. 21:39:52Z 1-EMIT — workload emitted and attested by the issuer {'sent': 50, 'attested': 50}
3. 21:39:52Z 2-RAIL — snapshots sealed and durably admitted by NEOfX {'snapshots': 2, 'edge_id': 7101, 'epoch': 9, 'frames': [1, 1]}
4. 21:40:03Z 2-RAIL — NEOCL receipts {'sealed_or_anchored': 2, 'pending': 0, 'statuses': {'sealed': 2}}
5. 21:41:33Z 2-RAIL — NEOva2 proof bundles {'bundles': 1, 'roots_pending': 0, 'positions': [39]}
6. 21:41:33Z 2-RAIL — public hourly units {'hours': [3720], 'roots_without_hour': 0}
7. 21:41:33Z 3-KILL — issuer stopped and its journal removed from the path {'issuer_alive': False}
8. 21:41:33Z 4-VERIFY — offline verification finished {'rc': 0}

Self-test inside the verifier: a tampered copy of one decision fails (content_rehash, era_sealed); a fabricated decision fails (content_rehash, snapshot_present, neof_receipt_present, neocl_receipt_present, bundle_present). Full result: verify.json. Kit samples: events, paths, snapshots, door receipts, ledger receipts, proof bundles, hourly unit.

Not proven here, by design: the era seal (the bundles say eraseal: null; witnessed ≠ sealed). Verified ≠ business success; verified ≠ content-authenticated.

Buyer and seller, same relation from the contract number alone, three documents each, one 32-byte commitment each

Each edge proves its own period from its own kit: records → record hashes → snapshot root → commitment == door payload → ledger leaf recomputed → beat root → bundle → hourly unit. Real iron: Telemach (hvar1, hvar2) → production door → production ledger → production archive.

A relation opening is a trading relation named between two companies plus one durable book record of it; nothing crosses the network per opening. Each process seals once per second: one 32-byte commitment in one frame, whatever the second held. Every second of the run was above 10,000 openings/s (59/59). The door admitted all 1,320 frames offered, 22 per second on average; every snapshot root was recomputed from its record hashes and every downstream proof checked; 3,960 randomly sampled records were recomputed from the record itself — all passed. Every record can be verified the same way; we did not recompute all 935,279. Where the limit lies was profiled only on the edge side (pure-Python canonicalisation 57 %, one fsync per record 24 %, small virtual machines); rail-side load and latency under this test were not measured against a baseline, so we make no claim about the rail's headroom from it. Files: summary.txt · verdict per kit · one kit's verification.

The NEO Chamber (membership, bind, decisions as attested records) witnesses every checkpoint root of its own chain to the same ledger — 2 checkpoints proven on 4 September: position [37], witnesses neo-5, neo-6, bundle and hourly unit valid offline (chamber_verify.json). Overlays add records; they never rewrite the core.

Someone else's calculator

The package below holds the demonstration data of demo 1 and our reference verifier, designed to check the chain from each record to its witnessed position and public unit offline. What the verification relies on, stated plainly: the verifier and its vendored code (ours — read it; run.sh runs it with sockets disabled, so a PASS was computed from the files alone), the protocol rules it encodes, the member value you pass, and a witness registry you obtained from a source you trust — from this zip alone you check our claim with our keys, which shows the mechanics, not an independent confirmation of the witnesses. Requirements: Python 3.11+ and the cryptography library. We are the bookkeeper: this proves what was recorded and witnessed, and when — not that a record's business content is true.

unzip neo-trade-verifier-2026-09-05.zip && cd neo-trade-verifier   # or neo-verifier-2026-09-04.zip
python3 -m venv .venv && . .venv/bin/activate && pip install cryptography
bash run.sh
# last line: {"verdict": "PASS", "events": 50, "passed": 50, "failed": 0, ..., "positions": [39], "hour_periods": [3720], "omission_gaps": []}

Then change one byte in kit/events/*.json and run again: that decision fails, the others pass. Duplicate a record under another name: the kit-completeness check names the gap. The public unit named HOUR spans 60 seconds in the current epoch; the era seal is not proven.

1. One deal. The Ariba-shaped buyer and the Alibaba-shaped seller name the same relation from the contract number; order on one side, confirmation on the other; two Studio Rail panels, two books.
2. The 32 bytes. A hex dump of the actual frame: header plus one 32-byte commitment — nothing else leaves either company. The live page shows the door receipt, the ledger seal, the witnessed position and the public unit as they happen.
3. Volume. The paired fleet runs live on the live page: deals per second, frames admitted, positions appearing.
4. Their calculator. Someone on the call verifies both kits on their own laptop with the package above — the same deal, both books, same relation, both positions; then tampers one byte.
5. And it survives its issuer — one minute of demo 1: the emitter is gone, the proof stands.
6. The ask. An Ariba / Business Network sandbox so the buyer's documents are real for the General Assembly; which ApeiroRA seam; which first workload.

Bounded on purpose: one workload, semantics before scale; 10,000 nodes is multiplication of the same container. Nothing on this page is a promise about the 8ra General Assembly; it is what runs today.