Prismux will never ask for a credential on this page. There is no password box, no API key box and no payment box here, disabled or otherwise, because a public page is exactly where a convincing one would be put by somebody who was not us. The button above authenticates nothing: it reveals sections of this page your browser has already downloaded, and the button beside it puts them back.
Nothing about you is stored here — no cookie, no local storage, no token. Close the tab and nothing remains. This page reads a captured chain, so the button opens the console rather than opening an account.
These receipts were written by the router on a loopback address against its synthetic upstream. Every one of them carries mock: true, the served endpoint id is rewritten ep_mock_*, and both facts are inside the hash. No real vendor credential has ever been used by this software. The routing, metering, pricing, ledger, vault, signing and chaining are the shipped code paths; only the socket at the far end is synthetic.
The window is minutes rather than a month because that is how long the run was. Nothing here is extrapolated to a billing period, and no figure on this page describes a customer, because there are none.
The second line is the router’s public signing key, printed at boot in the form prism verify --keys reads verbatim. Save it as prismux-receipts.pub, download the chain below, and the check runs with no network call and nothing of ours on your machine except an open-source binary. The --invoice figure is this page’s own total, so a mismatch between the two is visible rather than silent.
The same chain, checked by the CLI
Output, not illustration. This is what the verifier printed against this exact file at capture time, with the key above and no network access. Two independently written implementations of the canonical form agreeing across every record is the claim; one implementation agreeing with itself would not be.
The total on the last line is the same figure this page sums for itself, reached by different code reading the same records. If the two ever differed, one of them would be wrong and you would be able to see which.
Three checks, reported separately because they fail for different reasons: a content hash proves no field was edited, a link proves no record was removed or reordered, and a signature proves we issued it. A single green tick over all three would hide the one failure a customer most needs to see — a record that hashes correctly and no longer links.
The arithmetic behind the total
Not a model of how the price is formed — the receipts’ own decomposition, summed. Provider cost plus margin equals what you were charged, and if the two do not add up to the third this page says so instead of showing the third. What we absorbed sits beneath the sum rather than inside it: it is a cost increase we ate, so it never reached your total.
| Line | Amount | Receipt field |
|---|
The same total, cut four ways
One total tells you what the window cost. These four tell you where it went — by organisation, by the model you asked for, by the endpoint that answered, and by day. Every row is summed here, in this browser, from the receipts below; switching the cut re-reads the chain rather than re-slicing a summary somebody else prepared.
| Organisation | Requests | Delivered | Attempts | Tokens in / out | Substrate cost | Charged | Share of charge |
|---|
Substrate cost is what the attempt cost us; charged is what the record says you were billed. Both are read off the receipt as decimal strings and added as integers in micro-USD, never as floating-point dollars — the columns add to the same total the CLI prints, and a rounding step in here would be the reason they stopped.
By requested model
The model you asked for, not the endpoint that served it. The two differ whenever the ladder moved, and the endpoint table below is where that shows.
Why attempts failed
Read off ladder[].reason, a closed enum the schema keeps closed precisely so this aggregation is possible. It is never free text, so a reason cannot quietly become two.
Refusals
The chain does not record why. A refused request writes a receipt with delivery: none and posture: refused, and nothing else about the cause: the error code that named the binding constraint went to the caller in the response body and was never a signed field. So this panel can tell you how many, and when, and under which credential — and it cannot tell you which of them were residency, which were eligibility, and which were credit. That is a gap in the receipt format, not a rendering choice, and it is named here rather than filled in with a guess.
Metering divergence
We count tokens in the stream and keep the vendor’s number beside ours rather than adopting it. Both are on every receipt, so the divergence is a figure you can check rather than one you have to be told.
Which substrate actually served you
One row per endpoint that delivered tokens, with the jurisdiction whose law reached the bytes. The rows in brass were served by an endpoint the rate card records as having no published price — and they were charged anyway. The amount is stated under the table rather than netted out of the total.
| Endpoint | Vendor · substrate | Law | Requests | Tokens in / out | Charged | Price |
|---|
Ten of the twelve endpoints in the catalogue have no published price, and the two that do carry the URL and the date we read them from. See the catalogue for the source of each number and the reason each gap is a gap.
Which key paid for what
The chain carries key_ref — a reference that names a credential and cannot be replayed as one. It does not carry the label; that comes from the credential register, which is a different source, and the two columns are kept apart here so you can see which fact is signed and which is merely ours.
| Label (register) | key_ref (signed) | Requests | Charged | First → last | State |
|---|
Contracted tier, per receipt
Retention posture delivered
The tier is an account-level contract, not a per-request checkbox, and every receipt records the tier it was served under together with the seal that was actually applied. On this run the seal is our_key — envelope encryption to a key we hold. Nothing here was sealed under a threshold, because there is no escrow holder.
Vault and unseal events
A zero here is worth something only because the counter can rise: every attempt to open sealed content, successful or refused, is written into this chain as a record you hold. The absence of unseal events across a period is therefore evidence about that period rather than a promise about it — which is the one claim on this page that a hash chain is genuinely necessary for.
Our counters against your receipts
The left column is what the router counted in memory and published on /health. The right is what this page derived from the chain, independently. They are printed side by side because two numbers that agree are worth more than either alone, and because a row where they disagree is the row worth reading.
| Counter | Router | Derived from the chain | Agreement |
|---|
Chain head at capture ·
The check the hash chain cannot do
A hash chain catches an altered field and a record removed from the middle, because the record after it stops linking. It cannot catch a record removed from the end — nothing pointed at it, so every remaining hash, link and signature still verifies. That deletion is invisible by construction, and it is the one an operator with a motive would choose. What catches it is the other side of the house: the double-entry journal booked revenue per settled request, and the three figures below come from there rather than from the chain.
| Check | Router journal · /health | The file you hold | Verdict |
|---|
Both sides of it are ours. A rewrite that removes a receipt and lowers the published revenue figure in step passes all three rows, so this bounds an accidental loss and a one-sided edit — not a coordinated one. Closing that needs a figure published at a time you can pin and we cannot retroactively move: a daily chain head, or a countersignature from someone who is not us. Neither is built, which is why the completeness tile above is brass however these rows come out.
The same money, at four depths
The figures above are totals. This is the walk down from them: the whole signed chain, the runs inside it, the request inside a run, and every attempt inside a request. Each level opens in place, so a turn you open sits beneath the row you opened it from, and that row is still there when you close it again.
A receipt names the organisation, the credential and the model it was asked for. It does not name a conversation. There is no conversation_id, session_id or run_id in the receipt format or in any record on this page, so the runs below are derived, and not signed: consecutive receipts are cut into a run wherever the router sat idle for longer than the threshold on the tile above. Everything inside a run is signed. The boundary around it is ours, and it is the one thing here you cannot check against the chain.
Any figure, back to one record
Below: a receipt, the exact string its signature covers, and the hash recomputed from that string in front of you. The canonical form is what makes “signed” mean something — without it, a signature is a value you are asked to believe covers the fields you can see.
What this dashboard cannot tell you
Every item below is a thing a reader could reasonably assume from the rest of the page and would be wrong to. They are listed at the same size as the figures because a limit in smaller type than the claim it qualifies is decoration.
- completenessThe chain proves integrity, not completeness. It catches an altered field and a record cut from the middle — and not one cut from the END, which breaks no link and leaves every signature valid. The journal reconciliation below catches that, and it compares our number against our number. An anchor published at a time you can pin — a daily head, a monthly root — is what would make completeness provable, and neither is built:
grep -ric merkle router/src/finds two comments and no code. - the signing keyThe key is printed at boot, not published. There is no
/.well-known/document to fetch it from and no rotation history, because one key has ever existed and it has never rotated. Pinning the line above protects you against a later change of key; it does not tell you the key was ours to begin with. - the upstreamNo real vendor credential has ever been used. Every receipt on this page is marked
mock: trueinside its own hash. The live forwarding path has been exercised against a fixture on loopback and against nothing else. - pricesTen of twelve endpoints have no published price. Requests to them were charged anyway: those receipts read
priced: falseand carry a non-zerocharged, which by the schema’s own reading is a charge with no published rate behind it. The amount is named on the endpoint table rather than netted out. There is also no published Prismux rate anywhere, because none is contracted. - rate limitsPer-organisation limits are enforced inside one process. Fair queueing, per-endpoint ceilings and the learned back-off from an upstream 429 are real and were exercised here. There is no shared state across nodes, so two routers would each enforce your limit and you would get twice it.
- zdr_escrowThe threshold tier cannot be sold.
zdr_escrowneeds an independent holder and a customer share, and we hold neither set of keys, so the router refuses a request contracted at that tier rather than sealing it to us and calling it escrow. Every seal on this page isour_key. - the data sourceThis page reads a captured chain, not a live account. The per-organisation aggregate API is being built; until it lands there is nothing to poll, and a dashboard that appeared to refresh would be animating a fixture.
- runsA run is derived from timing, not read off a record. The receipt carries no conversation, session or run identifier, and the router signs neither
X-Prism-ProjectnorX-Prism-Idempotency-Keyinto it. The grouping below is an idle-gap cut, and the tile beside it prints the widest gap it kept inside a run and the narrowest it split on, so the distance between the two can be judged rather than taken on faith. A workload that paused in the middle of one conversation is shown here as two runs, and nothing in the chain would contradict that. - the last attemptWhy the final attempt failed is not in the chain.
ladder[].reasonis the closed enum explaining the attempt before it, so an attempt that fails with nothing after it has no reason recorded anywhere. Two receipts here are in that state and their rows readnot recordedrather than borrowing the enum from a neighbour. The error code that named the binding constraint went to the caller in the response body and was never a signed field. - schema conformanceSome receipts here do not validate against the published schema. The vault writes
vault.mode: "managed"and the published enum admits onlyoff,envelopeandthreshold_2of3. The chain verifies; the document contract does not, and the divergence is shown rather than hidden because a schema nobody checks is documentation.
The capability table on Status → what is actually running supersedes anything on this page it disagrees with.