Check a receipt.

what a pass here means

1. signatures

   Ed25519 and ML-DSA-44 both check out over the canonical body, against a key id the page pins. Two signatures because one is expected to outlive quantum computers and the other is what everything can check today. A four-element envelope — what stripping the post-quantum signature looks like — is refused in every conformance class.

2. the bindings

   The signed body binds a request hash to a response hash, under a pinned weights_digest and a pinned enclave_measurement, at a time, for a tenant. Change any one of them and the signature stops covering the receipt. What those two digests do and do not prove — commitment for an externally served model, computation for one inside the enclave — is written out on Proof of Model.

3. sealed

   With an inclusion proof, your browser recomputes the receipt’s ledger leaf from the signed body, walks the path to the day’s state root, and checks the seal’s signature against the key published at /ledger. The leaf is recomputed rather than taken from the proof: a proof carrying its own leaf hash proves the inclusion of whatever that hash is, which need not be your receipt.

what a pass here does not mean

• Not that the receipt describes your conversation. The receipt carries hashes, never content. Binding it to what you were actually shown means hashing that text yourself and comparing — which is the point of publishing the digests rather than the prose.
• Not a production receipt. Every example on this page is signed by a test key, because the attested gateway is in build and no production inference receipt exists yet. When one does, its keyset publishes beside the anchor document and the page checks against that.
• Not training-data provenance. A digest pin says which artifact answered. It says nothing about how that artifact was made, and no amount of signing will make it say otherwise.
• Not a verdict issued by a chain. An anchor witnesses that a commitment existed by a certain block. What was measured is checked by you, here, against published artifacts — the mechanism is written out on the ledger.

what this page sends

Nothing. There is no validate endpoint behind this box, no key that lives on a server, and no request carrying what you pasted — not to us, not to anyone. The signature check is arithmetic over files your browser already has, so it works with the network cut once the page is cached. Checking the seal is the one step that fetches, and what it fetches is the published checkpoint package and the anchor document, at fixed paths on this origin, chosen by this page rather than by the document you pasted.

That asymmetry is the product, not a limitation of it. Issuing receipts is the metered half; checking them is free, unauthenticated and permanent, because a proof you have to ask the seller to confirm is not a proof. The same verifier runs in the MCP server for agents, and as a command line for anyone who would rather not trust a web page either.