Public verifier · No signup

Verify any Clarify receipt. By hash. By anyone.

Every Promise and every Receipt sealed inside Clarify carries a SHA-256 hash over its canonical contents. Paste the hash below and we will confirm the Receipt was sealed against a real engagement, when it was sealed, and what kind of record it is. No login. No account. No tracking.

You do not have to trust us. You verify.

64 hexadecimal characters, lowercase. Receipt hashes appear in every Clarify export (PDF metadata, CSV header, JSON top level) and at the bottom of any Receipt your counterparty received.

SAMPLE FORMATWhat a 64-character hex hash looks like

0000000000000000000000000000000000000000000000000000000000000000

This sample is shown for shape only and will resolve to “not found.” To verify a real Receipt, use the hash printed on the Receipt you were sent.

Who this is for

A hash is a permission slip you do not need to ask for.

Auditors

When the audit committee asks whether vendors are delivering against the SOW, the auditor receives a Receipt packet, picks any line, re-runs the hash on the row contents, and confirms the record has not been altered. No follow-up email to Clarify. No call to your team.

Counterparties in dispute

A vendor claims they delivered. You have a Promise that says otherwise. They send a Receipt hash; you verify whether the Receipt is sealed against your engagement or it is not. No legal back-and-forth to establish whether the document is real.

Board members

When a board pack cites Receipts, a skeptical board member can pick lines at random and paste the hashes to confirm them. The metric stops being marketing the moment a board member runs a check on their phone.

Procurement reviewers

When a security questionnaire asks how you prove vendor performance, you can attach a Receipt packet. The reviewer verifies a few hashes and moves on, because the proof is in the bytes, not in your narrative.

How the hash works

Content-addressed, deterministic, independently verifiable.

When a Promise is sealed or a Receipt is logged, Clarify canonicalizes the record (owner, due date, signers, evidence references, every byte in a deterministic order) and runs SHA-256 over the resulting bytes. The 64-character hex output is the Receipt's permanent address. The same record always produces the same hash; any change to the underlying bytes produces a different hash.

The hash lives on the record itself, on every export it appears in, and on every Receipt your counterparty receives. The verifier on this page takes a hash, looks up the underlying record, re-runs the canonicalization and hash, and confirms a match. It returns the kind of record, when it was sealed, and the engagement it belongs to.

Nothing about this is proprietary. SHA-256 is the same hash every public blockchain, every Linux package manager, and every certificate authority uses. Anyone with the canonical bytes can verify the hash locally with any SHA-256 implementation, without ever talking to our servers.

Honest scope

What a verified hash proves, and what it does not.

Proves

The record exists in Clarify and has not been altered since it was sealed.
The record was sealed at the timestamp recorded on it.
The signers attached to it were the parties at the time of sealing.
The record belongs to the engagement and workspace it claims to belong to.

Does not prove

That the underlying work itself was good. A Receipt verifies that the work was claimed and signed, not that the deliverable meets your needs.
That the signers had the authority you wished they had. The signers are who Clarify recorded.
That the original SOW was fair. Verification is downstream of contract terms.

Want a hash of your own to verify?

Sign in, create an engagement, log one commitment, seal one Receipt. The hash on that Receipt will resolve here. That is the entire demo.