REPORT VERIFICATION · SHA-256 · NO ACCOUNT

Is the report you were handed the one we actually issued?

Hash the file on your own machine, then paste the digest. Nothing is ever uploaded.

Verify a report Request an Audit
A reviewer with braided hair, in a green blazer, seated at a dark stone desk by a window in a warm, low-lit office, signing a printed page with further papers and a stoneware cup beside them.
Sealed at generation, not on request
SHA-256 Hash chain Article 12 Append-only No upload

Our promise

“A report can be edited. The digest cannot.”

You hash the file on your own machine and paste the digest — the report is never uploaded, and we are never asked to confirm our own claim. The chain is re-walked every time.

Verify a report
The case file

Report provenance, in three chapters

The Seal

Every report is fingerprinted the moment it is generated. We take the SHA-256 digest of the exact bytes about to be delivered and seal it, together with the audit reference, the version and the time of sealing, into an append-only ledger — before the file has been sent anywhere at all.

The Doubt

A PDF is the easiest document in the world to alter, and an assurance report is one worth altering. Nothing on the face of one proves who issued it: a logo can be copied, a signature block retyped, and a single figure quietly changed by somebody who never audited anything at all.

The Ledger

So the answer is arithmetic rather than assertion. You hash your own copy, paste the sixty-four characters, and we compare — then re-walk the whole chain from its very first entry, because a record that could be quietly rewritten would prove nothing at all about the file it holds.

The four results

Four answers. Yours is one of them.

The check answers about the bytes, and it says so however the answer falls.

The two that settle it № 01
  • Verified — the digest matches and the chain is intact
  • Your copy is byte-for-byte the file we issued, and dated
  • No record — nothing in the ledger answers to this digest
  • Modified after delivery, mis-copied, or issued too early
Report provenance · iDharma · Presented for assay
The two that mean try again № 02
  • Not a digest — the value pasted was not 64 hex characters
  • A truncated paste, a filename copied with it, or an MD5
  • Unverified — found, but our own chain check did not pass
  • Deliberately not reported as a pass, and flagged on our side
Report provenance · iDharma · Presented for assay
Know what is proved

The proof is arithmetic. The trust is not.

You

The person holding the file

You compute the digest yourself, on your own machine, with a command your operating system already ships. Nothing is uploaded anywhere and nothing at all is stored. That is what makes the answer yours rather than ours - you are checking our claim, not asking us to repeat it back to you.

iDharma

The office that issued it

We fingerprint every report the moment it is generated and seal that digest into an append-only ledger with the reference, the version and the time of sealing. We cannot quietly amend a sealed entry afterwards - every entry in the chain that follows it would stop verifying, in public, on this very page.

The catch

What a digest cannot tell you

It proves the bytes, not the judgement. A verified report is the exact file we issued; whether the findings inside it are right is a question about the audit, answered by the methodology and by the named auditor who put their signature on it. Never read a green result as an opinion on its contents.

What a letterhead says

“It has their logo on it, so it’s their report.”

What the digest says

These are the bytes we issued, or they are not.

One of those can be copied in an afternoon.

  • Who it is for
  • Boards & audit committees
  • Regulators & supervisors
  • Diligence teams
  • Insurers & underwriters
  • Enterprise procurement
Why it matters
A black binder closed on a dark desk under a low lamp, a blank brass label plate screwed to its face and a red ribbon carrying a wax seal holding the page block shut, with a clipped sheaf of papers, reading glasses and a fountain pen laid out beside it: a record closed and marked at the moment it was issued.
01 An assurance report is read by people who were not in the room for the audit. Its whole value is that it came from somewhere, and a PDF says nothing about where it came from.
02

A report is forwarded on, attached to a deal, filed with a regulator. By the third hand nobody can say which copy is original.

03

Changing one figure in a PDF takes minutes and leaves no mark on the page. It changes the digest, which is the only place it shows.

04

A log you could quietly edit would prove nothing. Ours folds each entry into the next, so rewriting one breaks every link after it.

The 60-second check

Three questions. Then you’ll know.

No email, no signup. A starting point, not a determination.

0 of 3

Custody -

A digest proves the bytes, not the hand. It will tell you the file is ours. It cannot tell you whether the person who sent it to you was entitled to.

The bytes -

Byte-for-byte, and it means it. Re-saving, re-exporting or printing back to PDF rewrites the file. The content looks identical and the digest is completely different.

The question -

One of these four is not a digest question. Provenance is about the document. Whether its conclusions are sound is answered by the methodology and the named auditor.

The life of a digest

Four moments, and the first one is the point.

The fingerprint is taken before the file is sent, not when somebody asks for it — which is the whole reason a later check means anything at all.

  1. Sealed

    At generation

    The digest is taken over the exact bytes and written into the ledger before the file is sent anywhere.

  2. Sent

    On delivery

    You receive the report. The digest travels with it in the covering note, and also stays in the ledger.

  3. Checked

    Any time after

    You hash your copy and paste it here. We compare it and re-walk the whole chain each time.

  4. Held

    If it is disputed

    The ledger entry is the record, and it is the same record whether the answer happens to suit us or not.

The trap

Almost every failed check we see is a file that was opened and saved again. The content is identical, the digest is not, and the result reads as though something is wrong with the report. Hash the file exactly as it arrived.

Property & proof

What the record holds, what the check proves

12 properties, and what a check actually demonstrates about each. The last three are the ones it does not reach.

File integrity SHA-256 over the delivered bytes
Your copy is byte-for-byte the file we issued, or it is not. One altered character changes the whole digest.
Record integrity Each entry folds in the hash of the one before
The chain is re-walked from genesis on every check, so a rewritten history fails publicly rather than quietly.
Issue reference The audit request the report belongs to
The reference and version the file was issued under, so a superseded draft cannot pass as the final report.
Time of sealing Article 12-style automatic logging
When the entry was written, taken at generation rather than asserted later by whoever holds the file.
Algorithm and signer Stated on the result, not assumed
Which digest algorithm and which signing scheme produced the entry, printed rather than left to be implied.
Append-only storage No update path, and no delete path
Entries are written once. There is no supported operation that edits one, which is what the chain enforces.
Independent checkability Anyone holding the file, and no account
A board, a regulator or a buyer can run the check without asking us, and without telling us they ran it.
Confidentiality A digest is a one-way function
The digest reveals nothing about the contents and the result names no client. Verification is not disclosure.
Revocation and reissue A corrected report is a new entry
Superseding a report seals a new version rather than replacing the old one, so both stay checkable afterwards.
Authorship of the copy Out of scope, and it matters
A digest says the bytes are ours. It says nothing about who forwarded them to you, or whether they should have.
Correctness of findings Out of scope, and it matters more
Verification is about the file, not the judgement. The findings answer to the methodology and the named auditor.
Reports predating sealing Provenance began when the ledger did
A report issued before sealing has no entry, so no record is the expected answer rather than a red flag.
The check

Ninety seconds, and you do all of it

No account to make, and nothing to send us.

  1. Hash the file

    One command against the PDF you were sent. Nothing leaves your machine.

  2. Paste the digest

    Sixty-four characters into the box. No login, no email, no upload.

  3. Read the manifest

    Reference, version and sealing date - or a plain no record of it.

Verify a report now
An auditor in a black trouser suit over a black top, with a dark bob, standing against a warm pale wall and pointing into the open space alongside.
Every entry, and the one before it.
Struck in your favour

Why the check is built this way round

You do the checking

The digest is computed on your machine, by you. We are not asked to confirm our own claim.

The record is append-only

Every entry folds in the one before it, so a rewritten history breaks the chain in public.

No account, no upload

No login, no email, and no file ever leaves your desk. Checking up on us costs you nothing at all.

It says what it cannot do

A verified digest proves the bytes and not the findings, and the result states that plainly.

Four marks, struck on every report.

The result

What you see

Every field the panel prints, and the one answer it is designed to give you plainly.

The verification result

One panel, and it states its own limits: whether your digest matches a report we issued, whether the ledger chain still verifies end to end, the audit reference and version the file was sealed under, when that entry was written, and which algorithm and signer produced it - with no client named and no contents revealed.

SHA-256

Digest comparison

The sixty-four characters you pasted, set against the digest sealed at generation. They match exactly, or they do not match at all.

Re-walked

Chain integrity check

The whole ledger is verified from its first entry on every request, so the answer is about the record as it stands now, not as it once stood.

Manifest

Reference and version

Which engagement the report belongs to and which version of it you hold, so a superseded draft cannot be passed off as the final one.

Timestamp

Time of sealing

When the entry was written into the ledger, taken at generation rather than asserted afterwards by whoever happens to hold the file.

Stated

Algorithm and signer

The digest algorithm and the signing scheme that produced the entry, printed on the result rather than left for a reader to assume.

Guidance

A plain no, when it is no

No record, not a digest, or chain unverified - each says which it is and what usually causes it, rather than implying you have been deceived.

Format & fee

Free, and public.

Access
Open to anyone holding a report
Input
One SHA-256 digest, 64 characters
Re-check
As often as you like — no limit and no record of who checked

An assurance you have to pay for is one we control — so there is nothing to meter here, and nothing asked of you.

Verify a report
Report provenance · Public verifier Free always
  • Digest compared against the seal
  • Full chain re-walked every time
  • Reference, version and sealing date
  • No login, no upload, no client named
Show your hand

Four things a verified check establishes

Provenance is not graded on confidence. Each of these is either demonstrable to a sceptical third party, or it is not.

The bytes,
matched

Your copy hashes to the digest we sealed at the moment of generation. Not a similar file, not a re-export, not a printed-and-rescanned one: the same bytes.

The chain,
intact

Every entry from genesis to this one still links. Nothing in the history has been amended since, because amending any of it would break the chain and show up right here.

The issue,
identified

The audit reference, the version and the date the entry was sealed. Enough to place the document beyond any doubt, and not one single field more than that.

The check,
independent

Run by you, from a command your own machine already has, against a page that needs no account at all. An assurance you have to come and ask us for is not one.

Four cards, and none of them is an opinion.

FAQ

Plain answers

How to hash it, what a match proves, and what it does not.

Verify a report
How do I get a digest from the file?

One command, already on your machine. Windows: certutil -hashfile report.pdf SHA256. macOS or Linux: shasum -a 256 report.pdf. Paste the sixty-four characters it prints.

Is my report uploaded to iDharma?

No. The hash is computed on your own machine and only the sixty-four character digest is sent. The file never leaves your desk, and a digest cannot be turned back into the document.

What does a match actually prove?

Two things: the file you hold is byte-for-byte the one we issued, and the record of issuing it has not been rewritten. It proves nothing about who sent it to you.

It says no record. Have I been given a forgery?

Usually not. The common causes are a re-saved or re-exported PDF, a partial paste, or a report issued before provenance sealing began. Send us the digest and we will tell you which.

Does a verified report mean the findings are correct?

No. Verification is about the file, not the judgement. It confirms the document is the one we issued; whether its conclusions are right is answered by the methodology and the named auditor.

Get started

Commission a report of your own

Every report we issue is sealed and checkable on this page from the day it is delivered.

What we need from you

Nothing you do not already have. Most of this is a folder someone can assemble in an afternoon, and we name the documents first, before you commit to anything.

  1. Which AI systems you build or use, and what each decides
  2. Which standard or statute you need to be read against
  3. Any documentation - model cards, contracts, DPIAs
  4. Whether you built the system, bought it, or modified one
  5. Who the report is for, and by when they need it

What happens next

  1. You send the five items we need.
  2. You get a scoping call within one business day.
  3. The report arrives sealed, and checkable here.
Request an AI audit
Sources & standing

Where this page gets its facts

What the claims on this page rest on, and what they are worth - stated, not assumed.

What it is built on

  • FIPS 180-4 — SHA-256
  • EU AI Act Article 12 — record-keeping
  • C2PA 2.x — content credentials
Sealing since
Report provenance, 2026
Chain checked
On every public request

What it means

  • A verified result is a statement about bytes and about our record of issuing them — not legal advice, not an assurance opinion, and not a warranty of anything inside the document.
  • Where our own chain check does not pass, this page says so rather than the convenient thing.

Scope & limitation

  • It verifies iDharma reports alone, and no other issuer’s documents.
  • It says nothing about who forwarded you the file, or whether they should have.
  • It is a chain-of-custody fact, never an endorsement of the findings inside.

A digest that should verify and does not?

Tell us

From Insights

What the report is worth

View all Insights →
METHODOLOGY NOTES

What Is an AI Audit? Scope, Standards, and What You Get

An independent review of what your AI actually does, measured against a named standard — not a certificate, and not a review of what the documentation says it does.

Read the notes
METHODOLOGY NOTES

How to Prepare for an AI Audit: The Readiness Checklist

Six things to have ready before the engagement starts. Assembling them takes a fortnight off the clock — and tends to find the first two findings before an auditor does.

Read the notes
STANDARDS EXPLAINED

What an AI Governance Framework Actually Contains

Five working parts, not a policy document. What each one has to do, how to tell whether yours is real, and why a framework is not the same thing as compliance.

Read the guide
STANDARDS EXPLAINED

ISO/IEC 42001, SOC 2 and NIST AI RMF: Which One Your Buyer Is Actually Asking For

One certifies an organisation, one is an opinion about controls over a window, one is a method with nothing to issue. What each covers — and what none of them answers.

Read the guide