A verifier we did not write from our own code
Anyone can build a checker that agrees with their own platform. We published the specification, had a second verifier written from that page alone, and published the defects the exercise exposed.
WHY A VENDOR-WRITTEN VERIFIER PROVES LITTLE
Shared assumptions hide shared bugs: when the same team writes the sealing code and the checking code, both sides can agree on a mistake, and the verifier reports a pass that means nothing more than internal consistency.
A specification nobody implemented is untested: publishing a document is easy, but until someone builds against it and fails, you do not know whether it describes the format precisely enough for an outsider to use.
Assessors ask the sharp version: what stops your verifier from agreeing with your platform because you wrote both? The answer has to be structural, not reassuring.
WHAT WE ACTUALLY BUILT
Written from the page, not the source: a second verifier was implemented against the published verification specification alone, in Python using the standard library plus one public cryptography library, with no access to RAIC source code.
It checks the whole pack, not one signature: the manifest hash, every artifact digest, both day-root modes (the linear hash and the Merkle commitment), the inclusion proof for a single record, the ECDSA P-256 signature, and the RFC 3161 timestamp token.
It runs in CI with networking disabled: the checks execute against real packs on every build with no network access, so nothing in the verdict can quietly depend on calling us.
The specification is versioned and frozen: text v1.4 is fixed for its version, so a pack verified today is verified against a document that cannot be edited underneath you.
SOMEONE OTHER THAN US WITNESSED THE SEAL
An outside authority stamps the day root: each nightly day root is submitted to an independent RFC 3161 timestamp authority, DigiCert as primary in the United States and FreeTSA as failover in Germany, and the returned token is stored with the seal.
The token binds a time we did not set: an examiner reads which authority issued the token and checks it themselves against that authority, so the claim "this was sealed that night" no longer rests on our clock.
Failover is named, not implied: if the primary authority is unavailable the failover issues the token, and the pack records which one did, because a named witness is a claim an assessor can test and an unnamed one is marketing.
WE PUBLISH THE DEFECTS INSTEAD OF PATCHING THEM QUIETLY
The exercise found gaps, as it should: where the specification was ambiguous or incomplete enough that an independent implementer had to guess, that gap is recorded in a public defect register rather than silently corrected.
A register is more useful than a clean sheet: a specification with no reported defects usually means nobody built against it, and a reviewer learns more from how a vendor handles its own findings than from a page of assurances.
Deviations get stated, not smoothed: the same posture governs evidence itself, where artifacts that cannot be verified are flagged unverifiable instead of presented as verified.
WHAT INDEPENDENT DOES AND DOES NOT MEAN HERE
Independent in interpretation: the second verifier was written without our code, from the published document, and it disagrees with our implementation when our implementation is wrong. That is the property being claimed.
Not yet externally attested: the exercise was run in house, and no third-party assessor has yet attested to it. We say so on the page rather than in a footnote.
Published on a quarterly cadence: we publish the exercise every quarter, and again whenever the verifier specification text version changes. A quarter in which a check fails publishes as a failed quarter with the defect recorded. Read the results at the verification attestation page.
Sealing is not correctness: a verified pack proves the record is unchanged since it was sealed and that an outside authority witnessed the seal. It does not prove the underlying governance decision was the right one.
Check it yourself: read the published verification specification, then paste a record's SHA-256 hash at our public verification page for a readable receipt that confirms RAIC issued the record while revealing nothing about the tenant, the contents, or the volume behind it. Scripted checks call the raw verifier endpoint, or verify offline with the published public key. Background on the wider capability set lives on Evidence Integrity and Verifiable Evidence Lineage.
Hand your auditor proof they can check
Professional tier free for 14 days. No credit card.
ActivateWalk a sealed pack, an inclusion proof, and a timestamp token end to end.
See it liveMSP, reseller, and audit-partner programs. Email the partner desk.
Contact partnersRhindon AI Risk & Integrity Cloud | raic.rhindoncyber.com | © 2026 Rhindon Cyber
