Verification

When you download an evidence pack, you get a ZIP file containing:

• Clause50-[org]-v[n]-[date].md — The canonical Markdown document. This is what is signed. Nothing else matters; this is the truth.
• Clause50-[org]-v[n]-[date].docx — The same document as a Word file for reading and printing. Presentational; the Markdown is authoritative.
• Clause50-[org]-v[n]-[date].pdf — The same document as a PDF (if PDF generation succeeded; a Gotenberg outage can produce a ZIP without this).
• manifest-bundle.json — The manifest (system metadata, evidence hashes, rule-pack version, etc.) and the Ed25519 signature over it. This is what gets verified.
• VERIFY-THIS-PACK.md — This file. A convenience guide with instructions and the signature in copy-pasteable form. NOT signed; manifest-bundle.json is authoritative.
• evidence/ — The evidence documents themselves, not just their hashes. evidence/README.md maps each row of the pack's evidence register to the file in this folder and to its SHA-256, so you can go from a claim in the document to the artefact behind it without contacting anyone. evidence/rollups/ holds the detail behind any high-volume records the document summarises rather than lists.

The evidence/ folder is what makes the register checkable. A pack that listed fingerprints and shipped no files would leave you comparing hashes against nothing, and would require you to ask the organisation being audited for the very documents you are auditing.

The Ed25519 signature covers only the manifest, not the document files. The manifest contains:

• SHA-256 digest of the canonical Markdown
• SHA-256 digest of the DOCX file
• SHA-256 digest of the PDF file (if present)
• System metadata: organisation, system ID, rule-pack version, generation time
• Per-requirement status (satisfied / partial / missing / stale / not applicable)
• Evidence count and per-item hashes
• Chain head (the append-only system hash chain)
• Key ID — which public key signed this

The signature proves that this exact manifest has not been altered since it was signed. If the Markdown hash in the manifest matches the actual Markdown file, you know the Markdown is authentic. The same for DOCX and PDF — if any file hash does not match, that file has been altered or is the wrong file.

Option 1: Online (recommended for most users)

1. Go to https://clause50.com/verify
2. Drag the ZIP into the verification page
3. The page will check the signature and hashes without uploading anything
4. Read the results — each check passes or fails independently

Option 2: Command-line, using our verifier — not yet published

This option is not available yet, and we would rather say so than have you go looking for a package that does not exist. Clause50 intends to publish its verifier as an open-source command-line tool you install and run on your own machine — the same code that produces the signature, so a pack that verifies against it verifies against the thing that signed it. It is not published today. Until it is, use Option 1 or Option 3, both of which work now and neither of which requires trusting us at the moment of checking.

When it ships, the shape will be roughly this — recorded so you can see what is coming, not so you can run it:

# Fetch the public key from the registry
curl https://clause50.com/.well-known/clause50-manifest-keys.json \
  | jq -r '.keys[] | select(.keyId == "key-2026-07b") | .publicKey' > key.b64

# Verify the signature (the open-source package includes the verification binary)
npm run verify -- manifest-bundle.json --public-key "$(cat key.b64)"

# Expected output: ✓ Signature valid.

Option 3: Manual — works today (for auditors with development tools)

1. Extract the ZIP and read manifest-bundle.json
2. Canonicalize the manifest field (CBOR or JSON canonical form, per IETF 7049 / RFC 8785)
3. Decode the signature field from Base64
4. Use tweetnacl or equivalent (libsodium, PyNaCl, etc.) to verify the Ed25519 signature against the published public key
5. Compute SHA-256 hashes of the Markdown, DOCX and PDF files and compare them against the manifest

The signature proves two things:

• This manifest was created by Clause50 (it matches the public key)
• This manifest has not been altered since it was signed

If the document hashes also match, you additionally know the Markdown, DOCX and PDF files are the originals that were signed — no bytes have changed.

The signature does NOT prove:

• That the evidence is accurate — a system can record false claims and sign them. The signature just proves Clause50 signed them.
• That the system actually complies — compliance is an operational matter. This document shows what the system can demonstrate; it is not the same as compliance.
• That the evidence set is complete — a party holding both the Clause50 database and the signing key can curate a subset of evidence and produce a valid manifest over it. (This is a limit every compliance-audit tool has, and most do not admit it. We prefer to say it plainly.)

If any check fails, the document may have been altered. What to do:

• Ask for a fresh copy from the organisation that sent you the pack. Re-download if you have the ZIP stored locally — email can corrupt attachments.
• If the check that fails is "signature not valid" — and the ZIP is fresh and complete — contact Clause50 with the details. This would be a bug.
• If a file hash does not match, the file was altered after signing. Ask the organisation for a fresh download.
• If the key ID is unrecognized or revoked, the ZIP was signed with a key Clause50 does not publish or has disabled. This suggests either a very old ZIP or a counterfeit. Ask the organisation for clarification.