Every figure on this page is read from the router, or absent
There is no availability history here, no per-model figures and no incident post-mortems, because the router has never served a production request. This page carried all three until this revision — including a failover event described down to 3,118 requests — and none of it had happened: every number was a literal typed into the HTML, with no data source behind it.
A status page is a record. On a product whose entire claim is that its records are checkable, an invented one is the most expensive thing on the site, and it is worse than an empty one. So it is empty, and it says why.
What is actually running
Read from the router's source, and — where the row says measured —
from a router started on 31 August 2026 with a signing key, a vault key and a
credential register, driven with real requests, and read back through
/health and prism verify. This is the section that
supersedes any capability claim elsewhere on this site: where a feature page and
this table disagree, this table is right.
| Component | State | What that means exactly |
|---|---|---|
| Receipt chain | running | SHA-256 hash chain, append-only log with the kernel append-only flag, one write per record, a torn tail skipped on resume. The canonical form is re-derived independently in the router and in the CLI and checked against a fixed reference, so the two agree by specification rather than by sharing a library. |
| Offline verification | measured | prism verify recomputes every hash and walks every link with no network call. Measured: a four-receipt chain verifies and exits 0; editing one record's charged field reports content hash mismatch and exits 1; deleting a record reports broken link and exits 1. |
| Receipt signing | measured | Started with --signing-key, every receipt carries an Ed25519 sig over its own content hash and the signing_key_id that made it. The public half is printed at boot in the exact form prism verify --keys parses, so pinning it is a copy rather than a conversion. Measured: signatures 4 of 4 verified against the key you supplied; flipping one base64 character in a signature drops that to 0 of 1 and exits non-zero. |
| Signed field coverage (PRF3) | running | The canonical form the signature covers is schema_version 3 and spans 44 fields — up from 11 — including org_id, key_ref, the whole promises block and the whole charge breakdown. Absent and empty are encoded differently (signing_key_id=~ versus signing_key_id=0:) so two receipts cannot canonicalise identically. |
| In-path metering | running | Five token classes counted in the stream — input, cache read, cache write, output, reasoning. Where a vendor reports usage we keep both numbers and publish the divergence; we never adopt theirs in place of our own. Where a vendor reports nothing, our count is a structural estimate with a declared ±15% band, stated on the receipt as an estimate rather than passed off as a measurement. |
| Stream integrity | measured | Every token the upstream emits reaches the client exactly once and in order, through the real relay, with the fixture handing bytes over in hostile chunk sizes split mid-JSON and mid-line. Measured at 20,000 deltas: 20,000 received, 0 missing, 0 duplicated, order preserved, and the CLI reassembled all 20,000 downstream. |
| The router's own /v1/models | measured | Measured: of 12 endpoints, 2 return a price with a rate_card_id and an observed_at, and 10 return "priced": false with null for price, id and date. Until earlier today the endpoint returned a price and an observed_at date for all ten endpoints the rate card names as having no published price, using the same invented figures this website carried. One residual: the rate_card_id this endpoint publishes for the two priced rows is a derived id rather than the card's own content address, so it will not match rate-card.json by eye. The receipt carries both — rate_card_id and rate_card_ref — so a charge is still reconcilable to the published card. |
| Rate card | running | Every price is content-addressed with BLAKE3 over its own canonical form and re-verified when the card loads, so editing a price without reminting it is a load failure rather than a silent reprice. The process refuses to start if that validation fails — it exits rather than serve requests it cannot price against a published, dated number. A catalogue endpoint that is neither priced nor explicitly declared unpriced also fails the load, and the priced-or-not fact reaches the receipt per endpoint. The boot banner states the count: 25 cards, 10 bound to an endpoint, 10 endpoints unpriced, 0 stale. See the catalogue. |
| Receipt schema conformance | checked | Every receipt this router emits is validated against the published schema by a check that runs in the release gate, on receipts produced by that run rather than on a fixture — a fixture drifts the same way and just moves the lie. |
| Double-entry ledger | running | Named accounts, no balance column — balance is a sum over the journal. Unbalanced entries are refused on two independent paths and margin cannot be posted to because it is derived. Integer micro-USD end to end. Reserve-then-settle with a write-ahead log, and an idempotency key that bills exactly once across a hard kill and restart. |
| Eligibility filter | running | Capability-superset filtering and hard residency enforcement, both failing closed and naming the constraint that bound — capability=vision, data_residency=CN — with the candidate counts and a specific next action. |
| Routing ladder | rung 0 on, rungs 1–2 built and off | Rung 0 — same model, different substrate — runs by default and did not change. Rungs 1 and 2 now exist and are off. The tables they needed are in router/src/substitution.zig: version adjacency has 2 entries, cross-vendor equivalence has 6. Both are small because the catalogue is five models wide, and the refusals are part of the table — claude-opus-5 has no cross-vendor row (nothing we serve is at its tier) and llama-4-405b has none in either direction, because it is chosen for open weights or a jurisdiction and an outage is not a reason to overturn that. Every row carries the capability basis it is claimed on, and what a row gives up is derived from the catalogue and compared against the prose, so a justification that stops being true fails the build. Reaching either rung needs two things no request header can grant: a per-key max_rung above substrate — a header can only ever tighten a rung — and cost_transparent pricing, because a locked price over a substituted route would pay us for your outage. A substituted leg carries rung: version or rung: equivalence inside the signed ladder_hash, promises.capability_degraded is computed from the served endpoint against the route you asked for, and x-prism-served-model names the model that answered. One limit, stated rather than found later: the response body still echoes the model you asked for, because on a streamed answer that field has left the socket before a failover can happen — the header, the trailer and the receipt carry the truth. |
| Live upstream path | exercised against a fixture only | There is a real TLS client with credential segregation, refused redirects and idle-based timeouts, it is wired into the request path, and --live has now been driven end to end — against tools/fake-upstream.py on loopback, with a fake key. No real vendor credential has ever been used. Every completion anyone has seen from this router is either synthetic or from that fixture, and the mock marks itself inside the receipt's hashed canonical form so it cannot be laundered into a real chain. |
| Authentication and tenancy | measured | Started with --tenants <register> the router authenticates every request; started with neither that flag nor an explicit --no-auth it refuses to boot and prints the three ways to fix it. Measured: no credential → 401, an unrecognised credential → 401. The register is an append-only pipe-delimited log — admin credentials, tenants, keys, revocations, refusals — hashed with SHA-256, and a minted key's plaintext is shown once and never stored. There is an admin surface for the lifecycle, on a separate credential type: POST /admin/orgs creates a tenant, POST /admin/keys mints its key and returns the plaintext once, and POST /admin/revoke withdraws one on a running router. Measured: minting then using a key succeeds; revoking it makes the very next request 401 with no restart; and the admin paths refuse a tenant sk_prism_ credential with 401, because an admin credential is a different wire form and the console enforces the separation. Credit is posted through POST /v1/admin/orgs/<org>/credit, global scope only, with the payment reference as the idempotency key so the same reference credits once however many times it is sent. Until an org is credited its balance is zero and admission control refuses its first request (see the row below), which is the ceiling working rather than a gap. Still to come: per-organisation rate limiting is not enforced. |
| Admission control | measured | A request is priced conservatively and a hold placed against the organisation's balance and against its period ceiling — in one critical section — before anything is forwarded. Both refusals are measured, on 2026-09-05, against the shipped binary. An org with no credit: credit_exhausted — “needs a hold of 0.004956 USD and the organisation has 0.000000 USD of available credit, so it was refused before anything was forwarded. Nothing was charged and no tokens were spent.” An org under a hard 0.05/day ceiling, refused on its 39th request: budget_exhausted — “0.046018 USD already settled in this period and 0.000000 USD held by requests still in flight. This one needs a conservative hold of 0.004956 USD, which would take the period over the ceiling… The period rolls at 2026-09-05T00:00:00Z.” The ceiling is tested inside the same lock that inserts the hold, so eight threads racing 1,600 admissions at a 100-unit cap are granted exactly 100 — the property test is in router/src/ledger.e0l, and it is what the word guarantee is standing on. A soft ceiling never refuses: it serves and returns x-prism-budget-alert, measured as soft;period=daily;limit_usd=0.002000;committed_usd=0.000000;this_request_max_usd=0.004956;period_ends_at=2026-09-05T00:00:00Z — the alert fires on the request that crosses the ceiling, not on the one after it, which is a distinction this router got wrong until its own test caught it. Still to come: no ceiling can be set per key or per project, only per organisation. |
| Vault | measured | Started with --vault-key, content is sealed at stream close. Measured: four requests sent with X-Prism-Vault: managed produced four receipts reading vault: {"mode":"managed","written":true} and a /health counter of vault.sealed: 4. The cryptography is AES-256-GCM per record under a fresh data key, wrapped per holder with X25519 and HKDF, with a Shamir 2-of-3 split proved exhaustively over the field. The holders are what is still to come: there is no KMS integration and no customer bucket, so the only holder is our own key — the boot banner says “our_key seals only (no customer or escrow holder configured)” — and there is no escrow agent, so zdr_escrow cannot be sold. |
| Retention posture floor | partial | The four-value posture floor (zdr_contractual … retaining) is enforced in the eligibility filter and fails closed. The posture it reads is no longer compiled in: every one of the 25 cards in router/data/rate-card.json and every one of the 10 unpriced endpoints now carries the retention block the schema defines, the loader installs those postures at startup, and a bundle in which any card, any unpriced declaration or any catalogue endpoint has no block fails the load and the router exits 71 — the same rule that already applied to a missing price. The compiled table in catalogue.zig survives only as posture_fallback, and the boot banner prints which of the two answered on every start, boring or not. The four contracted tiers — open, mdr, zdr_escrow, zdr_absolute — are configured in the type with their gating, their window and what we hold at each, and reach the receipt; zdr_escrow is configured and cannot be sold, because share 3 of 3 has no holder and no escrow agent relationship exists. What is still partial is the evidence: all 35 retention blocks read unverified, with evidence_url and verified_at null and a stated reason, because no DPA clause, zero-retention addendum or verified organisation setting has been read for any endpoint. The provenance is now accountable rather than absent, which is not the same as present. As of 2026-09-02 the loader also caps what an unverified block may claim: a retention block with verification_state: "unverified" may only assert retaining, and a bundle claiming anything stronger fails the load and the router exits 71. Before that rule, nine endpoints asserted zdr_contractual while unverified, a request carrying that floor was served, and the signed receipt attested a guarantee no contract supports. Every posture we ship today is retaining, and a request demanding better is refused rather than quietly downgraded. |
| Prompt-cache economics | running | Warm-prefix affinity, a keyed fingerprint that never touches raw text, and correct per-substrate cache pricing — a prefix warm on one substrate is cold on another and the failover is priced as a cache write. We do not compute a break-even that would let a mildly degraded warm endpoint win anyway: it needs a health signal nobody has, and a tuned constant standing in for one is the guesswork this design exists to refuse. |
| Negative-margin breaker | running | Fed at settlement from what was actually charged against actually incurred cost, and consulted before routing: an endpoint whose breaker is open for a model is removed from the candidate set, and if that empties the set the request is refused with all_endpoints_unavailable and a receipt, rather than served at a loss we have already measured. A breaker does not close on its own — reopening a sales channel is a human decision with a re-collected rate card behind it. |
| Control plane | running | Eight admin routes behind a separate credential type: create an organisation, set its status, mint and list keys, revoke one on a running router, post credit, read usage and receipts, and the operator fleet view. Every one is global-scope gated and refuses a tenant credential. |
| Customer dashboard | a working demonstration, no accounts behind it | The page at /dashboard is a working demonstration reading a real signed chain, not a product surface with accounts behind it. What works: it reads the 287-receipt signed chain that ships beside it, recomputes every content hash, chain link and Ed25519 signature in your browser and reports the three separately, cuts the spend by organisation, model, endpoint and day, and walks each request down to the individual attempt inside it — where a failover leg that delivered nothing reads billable: false and adds zero to the charge. What does not exist: an account. There is no login, no session, no password and no per-organisation usage API to poll, so the entry panel is a named demo organisation and one button, it carries no field of any kind, and it says in its own copy that it authenticates nothing. The chain it renders is a captured file rather than a live account, and every receipt in it carries mock: true inside its own hash. |
Promise counters
The counters exist and are published on the router's own /health.
On a production deployment they would all read zero, because there has been no
traffic. Every one of them is incremented from the request path, so a zero is a
statement about the traffic and not about the counting.
| Counter | State | What that means exactly |
|---|---|---|
| requests · refusals · failovers | increments | Wired to the request path. Measured rising with traffic on a local run. |
| split_deliveries | increments | Streams that stalled after delivering tokens and were retried elsewhere. |
| metering_variance | increments | Divergence between our in-stream count and a vendor's reported usage. |
| absorbed_deltas | increments | Cost differences we ate rather than passed on. |
| sse_lines_dropped · receipt_write_failures · rate_card_stale · below_margin_floor | increments | Wired. |
| retention_downgrades | increments | Requests served by an endpoint whose retention posture is weaker than the one the request asked for. The eligibility filter refuses below the floor, so the only way to reach this is the explicit per-request consent header that reopens it — and a downgrade you agreed to is still a downgrade, which is why it is counted rather than assumed away. |
| capability_degrades | increments | Requests where the endpoint that served held less than what was asked for. Two halves, both measured at commit against the endpoint that actually served. Against the request: the filter refuses rather than degrades, so that half should stay at zero, and a zero that is compared every time is a measurement rather than an assumption. Against the route you asked for: on a key that opted into rung 1 or rung 2 the model can legitimately change, and a cross-vendor peer can hold every capability your request used while still doing less than the model you named — that is exactly what this counter is for, and it is why the number is not expected to be zero on a key with the ladder turned up. |
| vault_write_failures | increments | Seals that did not happen: an encrypt that failed, or a store that would not take the record. Counting one never fails the request — a copy we could not keep must not become an answer you do not get — and the receipt for that request reads vault_written: false, so the gap is visible from both the counter and the chain. |
A counter that cannot rise is worse than a missing one, because a zero reads as evidence. Each row above is driven by a test that forces the condition and asserts the number moved, and the router's own suite refuses any counter this page publishes that no code path writes.
Availability
We intend to publish two numbers and never one blended figure — router availability (we accepted, routed, metered and receipted correctly, given a healthy upstream) and effective availability (your request got a usable answer, bounded by the union of your eligible endpoints and therefore by your own policy). Both are settled in shape and neither has a value, because there is no traffic and no deployment behind them.
The values come from the router's /health, never typed into this
page, and they arrive here with the source and the window stated beside them.
Incident history
None. There have been no incidents because there has been no service. The two previously listed here — a control-plane index migration on 2026-08-14 and an elevated-failover event on 2026-07-29 — did not occur and have been removed rather than reworded.
Post-mortems are published for anything affecting the integrity of the receipt chain, retention guarantees, or billing correctness — including what we got wrong. Policy: Trust → incident policy.