How verification works

The audit trail is append-only

Every action on an account — a certificate uploaded, a field corrected during review, a flag dismissed — is written to an audit log that supports no edits and no deletions, enforced at the database layer, not just in application code. Corrections are recorded as new entries showing before and after values; nothing is ever rewritten in place.

Records are cryptographically timestamped

When a certificate is verified, we compute a SHA-256 fingerprint of the record — a fixed-length value that changes completely if even one character of the record changes. That fingerprint is hash-anchored with independent public timestamping services outside our infrastructure. The same is done daily for the audit trail as a whole.

The consequence: once a record is anchored, any later alteration — by anyone, including us — is detectable, because the altered record no longer matches the fingerprint that was independently timestamped.

What this does and doesn’t claim

Timestamping proves a record existed in a specific form at a specific time, and that it hasn’t changed since. It does not prove the record was accurate when created — that’s what the human verification step is for: extracted certificate data is never treated as verified until a person confirms each field against the source document, and that confirmation is itself an audit-trail entry.

Verifying independently

Each anchored record stores its fingerprint and timestamping receipts. Your team can recompute the fingerprint from the record and compare it to the anchored value at any time. For a walkthrough of independent verification against the public timestamp records, contact us — we’ll provide the receipts and tooling for your specific records.