How it works

Three mechanisms, each doing one job. None of them requires Audrie to hold your document.

1. The hash is the document

A SHA-256 hash is computed on your side — in the browser, in your CLI, in your integration — and only the hash is sent. Audrie's storage holds hashes and metadata; it holds no document content, and no endpoint accepts your document's bytes.

This is a structural property rather than a privacy setting, and it is why Audrie can be used on documents it would be unlawful to upload to a third party.

The consequence you have to design around: Audrie cannot tell you what a document says. It can only tell you whether the exact bytes you hold match a record. Change one byte and the hash changes completely.

2. Records are signed with ML-DSA-65

Signatures use ML-DSA-65 (FIPS 204), a lattice-based scheme standardised specifically because RSA and ECDSA do not survive a cryptographically-relevant quantum computer. Audrie's own seal over each record uses the same scheme.

This matters more for documents than for sessions. A TLS session compromised in 2040 is worthless; a signature on a deed, a trust instrument or a filing is supposed to still mean something then. A signature made today with a scheme broken tomorrow is retroactively worthless, which is the failure mode post-quantum signing exists to prevent.

Signatures and seals are stored per algorithm, so a record can carry more than one and a scheme can be added without invalidating what came before.

3. Every record is anchored to Hedera

Each record is committed to Hedera Consensus Service — a public ledger Audrie does not operate. The anchor carries the topic, transaction id, sequence number and consensus timestamp. A match is returned once its anchor is final.

Anchoring is pseudonymous: the committed message carries the document's SHA-256 and nothing else about it — no content, no filename, no identity. The hash is what makes the commitment checkable by anyone holding the same document, and it is public and permanent, so treat it as you would any other identifier for that file.

The anchor is what makes a verdict checkable by someone who does not trust Audrie. See verifying without Audrie.

What a verdict actually asserts

verdict is derived from four checks plus revocation state. It fails closed — anything Audrie cannot fully substantiate is never reported as verified.

Read checksPerformed rather than assuming. It is Audrie's word about Audrie's own records, and the contract's ChecksPerformed schema says which of its fields are genuine cryptographic recomputations and which report stored state. Those are different kinds of claim.

A verified verdict is also about the document, not about a party: it asserts that some valid anchored authentication exists, not that a particular person made it. Where several records match one hash, read each match's own status, signerStanding and signerHint.

Revocation reaches backwards

Two axes revoke, and they answer different questions.

A record can be revoked. status becomes revoked and revocation.reason says why. Read the reason: a document that was superseded was still validly signed at the time, which is a different fact from a key compromise.

A signer's standing can change, and that reaches back over records already made. If a signer's identity verification is withdrawn, every record they signed is revoked, whenever it was signed — the identity was never established, so nothing rests on it. Every other standing change (account closed, affiliation ended, under review) applies from its effective date forward: a record signed before the change stands on its own terms.

So a document that verified last year can correctly stop verifying today. signerStanding is recomputed on every verification, which is why a certificate issued earlier can disagree with a live verdict — and the live value is the current answer.