One neutral rail, two demonstrations

Every company keeps its own book; one 32-byte seal per company per minute leaves for a door

What this is. A provider here is one company of the consortium — a cloud, infrastructure or service provider in the 8ra sense — emitting its own audit records (who did what, to which resource, with what outcome) as ApeiroRA's audit-logging signal describes them. No company trades with another in this demonstration; no message passes between them. 150 companies is the consortium's size today; 10,008 is the network it describes. The marketplaces demonstration further down is the other case — two companies, one deal, two books.

What was built. ApeiroRA's audit-logging signal is OpenTelemetry: their Go SDK emits audit records, their collector forwards them, on their wire format. We put a NEO audit sink behind that wire. Every record lands verbatim in its company's own book and is answered with a receipt on the wire (record id, integrity hash, sink time); once a minute each book seals into one 32-byte commitment that leaves for a door. What the door sees is 10,008 objects a minute — whatever the record rate. Nothing else leaves a company: no record, no content, no counterparty.

How it was reached. First the small test that is the consortium's shape today: 150 companies × 0.5 audit records/s each × 3 minutes → 13,535 records, 0 failed, 74 requests/s, p50 1.7 ms; 2,249 seals admitted at the door, every one of them cross-checked against the door's journal and its kit verified (ALL OK, 2,249 periods — fleet150-3min.json · cross-check). Then the ladder at 10,008 companies with one disk sync per record: 3,577 / 4,235 / 4,719 requests/s at 0.5 / 1 / 1.5 records per company per second, 0 failed at every step (run 9). Then the sink's group commit — one disk sync per window of records, every request still answered only after the sync that covers it — and the two-hour run above at 8,140 requests/s (SUMMARY.json · completeness.json · crosscheck-summary.json).

And it survives its sink. Right after the run the twelve sink processes were stopped in the middle of their work — 26,793,445 records answered 200 but not yet in their books — and restarted. The sink's intake log replayed 26,628,445 records into the books, every company sealed and every seal was admitted — 10,008 → 10,008, 0 unadmitted — within 31 minutes of the stop, no operator in the loop (state-after-drain.json). A receipt a company holds is valid before, during and after. Three minutes at the same rate on the restarted sinks: 6,648 requests/s, 0 failed, 36,853 seals admitted (after-restart-smoke-SUMMARY.json).

Bounded on purpose: the twelve doors on this box are test doors with their own journals — the leg from those doors to the production ledger was not part of this run. Verified here means: the record is in its company's book, under a commitment the door admitted, with a kit that recomputes record → snapshot → commitment; it does not mean the record's business content is true, and a record never sent cannot be missed by any bookkeeper. Their SDK and collector were used as published; one box (16 vCPU, 62 GB) carried all of it.

• 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.