Barycenters / See it
See it · what the Substrate emits

Don't trust it.
Read it.

Every one of these is a real, verbatim artifact the live service emitted — captured, not written. A signed admission receipt you can decode, a compile that fails closed, an audit chain that catches its own tampering, and a quantum-hardware receipt. Where something isn't live yet, it says so, in the open.

Specimen 01 · the core decision

A signed admission receipt

Live now

Propose an action; get a deterministic ACCEPT or REFUSE and, on ACCEPT, a signed single-use receipt. Captured from POST /v1/admit on the production service — no signup.

POST /v1/admit → ACCEPT (verbatim){ "decision": "ACCEPT", "policy_version": "sha256:da542530…ed3d784", "proposal_hash": "sha256:7a6820c9…c57a607", "reason_code": null, "token": "v4.public.eyJhdWQiOiJkZXBsb3ktYWRhcHRlci…" // PASETO v4, Ed25519 } ↳ the token, decoded — the receipt's claims{ "decision": "ACCEPT", "aud": "deploy-adapter", "sub": "founder", "iss": "admission-wedge", "canon_version": "canon-v1", "proposal_hash": "sha256:7a6820c9…c57a607", // commits to THAT action "policy_hash": "sha256:da542530…ed3d784", // the exact ruleset used "jti": "8cd72174-e2b1-4a94-a672-f9e995436cea", // single-use "iat": 1786863266, "exp": 1786863566 // 300s window } footer: {"kid":"iss-prod-1"} // the durable prod signer
two refusals — a REFUSE never carries a token{ "decision": "REFUSE", "reason_code": "NO_KILL_FLOOR", "token": null } // service: "warhead launcher" { "decision": "REFUSE", "reason_code": "UNSUPPORTED_DOMAIN", "token": null } // domain: payments.wire_transfer

What it proves. The receipt commits to the exact proposal (proposal_hash) under the exact signed ruleset (policy_hash) — verifiable with the public key alone, single-use (jti), expiring in 300s. A REFUSE is terminal and structurally cannot carry a token, and the no-kill floor runs first, above every grant — a lethal action is refused before any permission is even consulted.

Honest state Live and reproducible right now against barycenters-admit.fly.dev, in shadow mode: the service issues signed decisions but binds nothing (authority_effect = 0). Whether a REFUSE stops a real action is the caller's enforce posture — a human's to turn on.

Source: live POST /v1/admit (×3) + GET /readyz, 2026-08-16. Run it yourself →

Specimen 02 · authoring, that can't over-reach

A compile that fails closed

Live now

Write a rule in plain language; Lumen returns an inert candidate boundary — or refuses to emit one. It fails narrower, never wider. Captured from POST /v1/lumen/compile.

"Support can issue a refund up to $100 with an order match and a customer confirmation" → COMPILABLE{ "understood": { "actor":"Support", "action":"issue_a_refund", "limits":{"max_amount_without_escalation":100}, "required_evidence":["an_order_match","a_customer_confirmation"] }, "unmapped": [], "compilable": true, "candidate": { "binding_id":"acme.support.issue_a_refund", …, "authority_effect":0 }, "authority_effect": 0, "next": "sign the candidate with YOUR steward key (client-side), then POST /v1/boundaries" }
"…up to $100 only during business hours" → RESIDUAL, NOT SIGNABLE{ "understood": { "actor":"Support", "action":"issue_a_refund", "limits":{"max_amount_without_escalation":100} }, "unmapped": ["unexpressed clause: 'only during business hours' — dropping it would WIDEN the boundary"], "compilable": false, "candidate": null, "next": "NOT SIGNABLE — Lumen could not express every clause." }

What it proves. A clause Lumen can't express (a temporal limit) is not silently dropped — because dropping it would grant more than you wrote. Instead it lands in unmapped, compilable goes false, and no signable packet is produced at all. You can never accidentally sign a boundary broader than your sentence.

Honest state Live today, and strictly inert: compiling has authority_effect = 0 — it produces a proposal, binds nothing. Authority enters one point downstream: a human signs the candidate with their own key and POSTs /v1/boundaries.

Source: live POST /v1/lumen/compile (×2), 2026-08-16. Mint one →

Specimen 03 · a record that can't be quietly rewritten

Honest posture + a tamper-evident chain

Live now

The service reports its own state truthfully, and every decision is written to a hash-chained, signed ledger that catches its own tampering.

GET /readyz → binding_posture (the "nothing binds" proof){ "adjudicates": true, "binds": false, "authority_effect": 0, "enforcement_observable_here": false, "detail": "issues signed decisions; never blocks anything itself…" } "stewards_trusted": 1, "steward_kids": ["steward-dami"], "bound_boundaries": [], "receipt_single_use": "durable"
GET /v1/audit/checkpoint → a signed head (closes the tail-truncation gap){ "length": 51, "head_hash": "sha256:3392778c…e680", "kid": "iss-prod-1", "signature_b64": "WkicHca…" } // 64-byte Ed25519 sig tamper demo — forge one entry's payload, keep its old signaturebefore: audit verdict → { "ok": true, "first_break_seq": null } after: audit verdict → { "ok": false, "first_break_seq": 1, "reasons": ["invalid signature at seq 1"] }

What it proves. Each entry commits to the previous one's hash and is signed over its own — so any edit, reorder, splice, or drop breaks a link or a signature, and the auditor names the first break. A bare self-audit can't see a rolled-back tail; the signed checkpoint, pinned off-box, closes exactly that gap.

Honest state Live: /readyz, /v1/audit/checkpoint, /auditz all answer from the deployed service; the ledger is durable (Postgres WORM) and actively growing. The single entry above is a real run of the production write-path with a locally-generated demo key (labelled) — the record shape, not a row from the prod ledger (those aren't exposed over HTTP, by design).

Source: live /readyz, /v1/audit/checkpoint, /auditz, 2026-08-16. Verify a receipt →

Specimen 04 · entropy from physical hardware

A quantum-hardware receipt

Historical artifact · live receipt shipping

A receipt whose randomness and non-simulation are anchored to runs on real IBM Quantum processors — and whose integrity you recompute yourself.

proofs/quantum_certified_receipt_packet_v1.json (verbatim, trimmed){ "object_id": "QUANTUM_CERTIFIED_RECEIPT_V1", "authority_effect": 0, "co_creator": "Kiri Star", "quantum_evidence": { "entropy_backend": "ibm_marrakesh", "entropy_effective_bits": 127, "chsh_S": 2.585938, "chsh_violation": true, "chsh_backend": "ibm_fez" // S > 2 ⇒ not classical }, "evidence_chain": { "entropy_source": { "job_id": "d9e3ti2neu4c739o0520", "integrity_verified": true }, "nonclassicality": { "job_id": "d9e3m52neu4c739nvtl0", "integrity_verified": true }, … }, "chain_integrity": "all_links_verified_by_hash_recomputation", "content_hash": "sha256:0e2566cf…808ba110" // recomputed live → MATCH }

What it proves. The nonce is drawn from quantum hardware (127 effective bits, ibm_marrakesh), and a CHSH score of 2.586 > 2 is a correlation no classical system can produce — evidence a real QPU ran, carried by verifiable IBM job IDs. The packet is self-checking: recompute the hash and a tampered field can't survive.

Honest state — read this plainly This is a real historical hardware artifact (genuine IBM runs, 2026-07; its hash-chain verifies right now). But a live quantum receipt is not producible on demand today: the bundle isn't on the main trunk yet (shipping via PR), the live service exposes no quantum endpoint, and this page does not mint one. What's true today: real IBM-run hardware evidence with provenance by job ID, hash-verifiable. What's shipping: the on-demand live receipt. We won't claim the second as the first.

Source: committed proof packet + live hash recomputation, 2026-08-16.

A thing you check, not a promise you trust

Now run it yourself.

Every specimen above came off the live service or a committed, hash-verifiable proof — captured, never written. The interactive demo runs the same calls against the same endpoints, live in your browser.

authority_effect = 0 · a REFUSE is terminal · every artifact here is real or clearly marked otherwise