Skip to main content
Verification is the claim this platform is built to survive: a reviewer should be able to check an artefact without access to your systems and without trusting us.

​
In the browser

rotascale.com/verify/ takes a record and its proof and checks them in the page. Nothing is uploaded. The verifier runs locally, which is what makes it reasonable to hand to a customer’s security team or a regulator.

​
What a passing check tells you

  • The record belongs to the sealed set the root commits to
  • Nothing in it has been altered since sealing
  • Where an external anchor exists, that the root existed by a certain time

​
What it does not tell you

This matters more than the list above.
A passing check says the record is intact. It says nothing about whether the decision was correct, whether the policy was sensible, or whether the deployment was configured well. Integrity is not judgement, and a verifier that implied otherwise would be selling a feeling.

​
What the signature covers

Every artefact prints its own procedure in seal.how_to_verify. Follow that rather than this page, but it says:
Remove signature and content_hash from the seal block, then re-serialise the whole document using canonical JSON (sorted keys, no whitespace, UTF-8) and verify the Ed25519 signature over those exact bytes.
Those two fields are held back because neither can be an input to its own computation. Everything else in the seal is covered, including custody, which is the field that decides what a verified signature is actually worth. That changed in seal_version: 2. Before it, the signature covered the document with the whole seal removed, so the seal’s own claims sat outside it: an artefact signed with an ephemeral key could be relabelled as customer-held custody and still pass every check. Documents carrying no seal_version are verified the older way and remain valid. They cannot be retrofitted, since their bytes are already signed, so rotascale.com/verify/ reports which kind it is looking at and tells you when a custody claim is not covered.

​
Keys

Verification uses published signing keys. Pin the key you expect rather than accepting whichever key the artefact names, otherwise you are verifying that the artefact is internally consistent rather than that it came from the deployment you think it did. The verifier surfaces a mismatch loudly rather than quietly falling back, which is deliberate: a silent fallback here would defeat the entire exercise.

​
Can the rest still be verified?

Checking one artefact tells you about that artefact. It says nothing about the proofs you were issued last quarter, and that is the gap worth closing before an audit rather than during one. The failure is silent by construction. If a deployment loses its signing key and starts sealing under a new one, nothing breaks. There is no outage and no error. Sealing carries on, and the problem appears only when somebody tries to verify a proof from before the change. GET /v1/evidence/continuity answers it, and the console renders it on Evidence. Four states, because fewer would mislead: A superseded hash schema is not a breach, and reporting it as one would send you looking for a backup of a key that was never lost. nothing_sealed is deliberately not reported as good news. “No breach was observed” and “no observation was possible” are different findings, and the answer always carries the number of roots it was reached over so you can tell which one you are reading. Add ?sign=true and the answer comes back as a signed artefact you can keep and re-check later, in the same envelope as every other artefact here.
A continuity statement is signed by a key the deployment holds, so it cannot be better evidence than its own custody. If a key had been lost, the statement would be signed by the one that replaced it.That is why it lists every key it holds and every key it cannot reproduce. Check those lists against proofs you already have. A verdict you take on trust is the thing this page exists to make unnecessary.