Check it here. Do not send it to us.

The artefact Public key, if you have one from elsewhere (optional, base64)

Verifying something a customer's deployment produced

This is the ordinary case: RotaGrant runs in the customer's environment and signs with their key. We did not sign it and cannot vouch for it — which is the design working rather than a limitation. A vendor who could vouch for every customer's evidence would be a vendor whose customers' evidence depends on that vendor still existing.

It is a keypair, and the public half is small

The private key signs

32 bytes that never leave the organisation's environment. It is never uploaded, pasted, downloaded or exported — the capability is absent from the interface rather than present and forbidden, and no route on the API could carry one.

The public key verifies

32 bytes — 44 characters of base64, like eHOPK3qP8zw5ii3tPKzZBC/ghbmD3fyiV17pZ1RnMns=. It cannot sign anything, so it is safe to email, print in an engagement letter, publish on a website, or read down a telephone.

Once, then forever

An auditor who has that string can verify every artefact that deployment ever signs — offline, with no call to the customer and no call to us. Neither of us needs to be reachable, or solvent, for last year's evidence to still check out.

The only part that needs care

The key must reach you by a different route than the document. Every artefact embeds its own public key, and checking against that proves the document is internally consistent — but a forger can generate a keypair, sign a fabrication with it, and embed the matching public half. It would verify perfectly against itself.

So: ask the organisation for their key, or for the URL where their deployment publishes it — every one serves it unauthenticated at /.well-known/jwks.json. Match the kid there against the key_ref printed in the artefact. Airgapped deployments are no harder: nobody needs to reach the instance, because 44 characters travel by email.

Ask what custody the key was under, and every artefact answers. A key held on the deployment means the operator could have re-signed a rewritten history; a customer-held or HSM key means they could not. The difference is stated inside the signature as custody, so removing it breaks the check.

What a passing check does and does not tell you

It does tell you

That the document has not been altered by so much as a character since it was signed, and that whoever held the private key signed exactly these bytes — including the disclaimer, which is inside the signed payload rather than beside it.

It does not tell you

That the claims inside are true of the world. A signature establishes integrity and origin. Whether an agent's record accurately describes what happened is a different question, and no signature answers it.

And whose key it was

If you verified against the key inside the document, you proved internal consistency and nothing about identity — anyone can sign anything with a key they generated. Pin a key you obtained out of band and the check answers who.

The verification contract is printed inside every artefact, in its own how_to_verify: remove signature and content_hash from the seal, re-serialise the whole document using canonical JSON — sorted keys, no whitespace, UTF-8 — then verify the Ed25519 signature over exactly those bytes. Everything else in the seal is inside that signature, including the statement of who held the key. Anyone can implement it; this page is a convenience, not an authority.