> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rotascale.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Verify an artefact

> Check a signed record or pack without trusting the party that produced it, and without sending it anywhere.

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/](https://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.

<Warning>
  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.
</Warning>

## 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/](https://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:

| State            | Means                                                                                            | Recoverable                                                                                                                     |
| ---------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
| `intact`         | Every sealed root was signed by a key this deployment still holds, under the current hash schema | Nothing to do                                                                                                                   |
| `stale_schema`   | Some roots were sealed under an older hash schema                                                | Yes. The older rules are published and each batch records which it used, so those roots still verify under the schema they name |
| `orphaned`       | Roots were signed by a key this deployment no longer holds                                       | No. Restore the seed if it exists                                                                                               |
| `nothing_sealed` | Nothing has been sealed here, so there is nothing to verify                                      | Seal a batch. Records can be complete and still unprovable                                                                      |

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.

<Warning>
  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.
</Warning>