Evidence Verifier Specification

Artifacts you can verify

Signed audit pack

A JSON bundle exported from Evidence Lineage. Contains sealed day roots, artifact fingerprints, lineage hops, a manifest hash, and a detached signature. Downloaded as RhindonCyber_SignedAuditPack_<date>.json.

Sealed day root

One SHA-256 value per organization per day, computed overnight over that day's ledger entries. A day root is fixed once sealed.

Continuity certificate

A signed statement that an organization has maintained an unbroken sealed evidence history through a 1, 3, or 5 year milestone. Exportable as PDF or DOCX, with the certificate hash printed on the document.

Hashing scheme

All digests are SHA-256, lowercase hexadecimal, 64 characters. Every ledger entry carries a digest computed over the canonical serialization of the event fields together with the digest of the entry immediately before it, which chains the entries into one continuous sequence per organization. A day root is the digest computed over that day's ordered entry digests. A manifest hash is the digest over the canonicalized pack manifest — the day roots, artifact fingerprints, and lineage hops it asserts. Canonicalization uses UTF-8 encoding with object keys sorted lexicographically and no insignificant whitespace, so any two implementations that follow this rule produce byte-identical input and therefore identical digests.

Signature format

Manifests and continuity certificates are signed with ECDSA over the NIST P-256 curve using SHA-256 as the digest. The signature is detached: it is computed over the manifest hash (or certificate hash) rather than the whole document, so a verifier recomputes the hash from the payload, then checks the signature against that hash. Signatures are base64-encoded. The active signing key is identified by the fingerprint 9a9980482b19bbc86b354122020c95c2, which the verification endpoint returns on every response so you can confirm which key was used.

Public verification endpoint

The endpoint is open, requires no account or API key, sends permissive CORS headers, and returns non-identifying facts only — never organization names, actors, artifacts, or personal data.

• GET https://app.rhindoncyber.com/api/public/verify-evidence?manifest_hash=<64-hex>
• GET https://app.rhindoncyber.com/api/public/verify-evidence?day_root=<64-hex>
• POST the same path with a JSON body of { manifest_hash, day_root, signature } — supply at least one hash.
• Include signature alongside manifest_hash to have RAIC check the detached signature for you; the response then carries signature_valid as true or false rather than null.
• Hashes must be 64-character lowercase SHA-256 hex. Anything else returns HTTP 400 with an explanatory error.

Reading the response

found

True when RAIC recorded the hash you supplied. False means the artifact was not produced by RAIC, or its contents were altered after export so the recomputed hash no longer matches.

kind

Which artifact matched: manifest, day_root, or certificate.

signature_valid

True or false when you supplied a signature; null when you did not. This is an independent cryptographic check, not a database lookup.

signing_key_fingerprint

The fingerprint of the key RAIC currently signs with — compare it to the published key you hold.

Verifying offline

Nothing in the scheme requires network access. An auditor working from an archived pack can reproduce every check locally.

• Canonicalize the manifest as described above and compute its SHA-256 digest; it must equal the manifest hash printed in the pack.
• Verify the detached base64 signature over that digest with the published P-256 public key, using ECDSA with SHA-256.
• For each artifact listed in the pack, hash the corresponding evidence file and compare it to the fingerprint recorded in the manifest.
• For each sealed day cited, recompute the day root from the ordered entry digests supplied in the pack and compare it to the recorded root.
• A break at any step localizes the problem: a manifest mismatch means the pack was edited, an artifact mismatch means a file was replaced, and a day root mismatch means underlying history changed after the seal.

Verifying a continuity certificate

A continuity certificate asserts an unbroken run of sealed days through a milestone. Verification is the same two-step check: recompute the certificate hash over the canonicalized certificate payload, then verify the signature over that hash. Submit the certificate hash to the public endpoint to confirm RAIC issued it. Certificates deliberately exclude tenant-internal detail — no ledger volumes, no gap dates, no record counts — so they can be shared with a prospect, a regulator, or an insurer without disclosing operational data.

What verification does not claim

Verification proves integrity and origin, not correctness of judgment. A passing pack tells you that the record you are reading is the record RAIC sealed at the time it claims, that it was signed by the RAIC evidence key, and that no entry, artifact, or day has been altered since. It does not assert that the governance decisions inside were sound, that a control is effective, or that the organization is compliant with any framework. Those remain the assessor's conclusions.

Telemetry and privacy

Each lookup records an anonymous adoption event: the artifact kind, whether it matched, and a coarse client descriptor. No organization identity, no requester identity, and no hash contents leave that record in a form that identifies a tenant. Telemetry never blocks or changes the outcome of a verification — if recording fails, verification still returns normally.

Getting the public key

The signing public key is published on request to auditors and examiners; contact [email protected] with the key fingerprint shown in your pack. Verify the fingerprint you receive against signing_key_fingerprint from the endpoint before relying on it for offline verification.