How to verify a signed document without trusting the vendor

If verification requires the vendor's website to be up and your account to still exist, it is not verification.

The point of an evidence package is that somebody with no relationship to your vendor can check it. Here is what that check consists of.

1. The document is the document

Take the file, hash it, and compare against the hash recorded on the certificate. This answers one question and only one: is this byte-for-byte the file that was completed?

It does not tell you who signed it, and it should not be treated as permission to find out. A hash proves possession of a file, not entitlement to know who signed it — which is why a public verification page should confirm only what the visitor already holds, read off the certificate they uploaded, rather than looking the document up in the vendor's records.

2. The certificate matches its own seal

Recompute the completion hash from the certificate's own contents and compare it to the one printed on it. If they match, nothing on the certificate has been altered since it was sealed.

Two caveats that a careful verifier reports rather than hides:

• If the certificate was sealed under an earlier definition of the seal, it will not match the current one. The correct response is to recognise it, say which definition it matched, and report it as valid under that one. Reporting it as "altered" is a false accusation about a genuine document.
• The seal only covers what it covers. See what a certificate of completion proves.

3. The event chain is unbroken

Each event in the trail should carry a hash covering the event before it. Walk the chain: recompute each event's hash from its contents, check it matches, and check the sequence has no gaps or reordering.

A gap here means an event was removed. A mismatch means one was edited.

4. Know the limit of what you just checked

This is where honest verification differs from confident verification.

If the event chain is global — one chain across everything a platform recorded — then a corrupted entry belonging to a completely unrelated document breaks the chain for yours too. That is a limit on what the platform can prove, not a finding about your agreement.

Reporting it as a failing check against the visitor's certificate turns "verified" into "does not check out" for a document that was entirely intact. The right behaviour is to withhold the claim it cannot support and say so as a caveat beneath the verdict, rather than asserting something false about somebody's agreement.

What the package should contain

• The completed document
• The certificate, as machine-readable data rather than only a rendered page
• The full event trail
• A manifest listing every file and its hash
• A verifier you can run yourself, offline

That last item is the one that separates a portable package from a folder of files. If checking the package requires you to reimplement the vendor's hashing scheme from a specification, it is not portable — and a verifier assembled from the platform's own hashing and chain code, rather than written a second time, is the only kind that cannot drift away from what it is checking.

Do it yourself, on a real one

Everything above is a description. Here is an agreement you can check without an account, without a network connection, and without taking our word for any of it.

Download the sample evidence package — about 12 KB. It is a completed agreement between two fictional companies, produced by the same code that produces a customer's. Unzip it, and run the verifier that came inside it:

node pactlyra-sample-evidence/verify.mjs pactlyra-sample-evidence

Node 22 or newer, nothing to install, and it makes no network requests. You should see this:

Pactlyra evidence — envelope ec2f41e1-7323-4911-b99a-30f6e62c7637
Completed 2026-03-03T08:09:30.000Z

The files
  ok   certificate.pdf: matches the manifest
  ok   certificate.json: matches the manifest
  ok   events.json: matches the manifest
  ok   signed.pdf: matches the manifest
  ok   manifest describes this certificate: the seal in the manifest is the one on the certificate

The evidence
  ok   completion hash: the certificate matches its own seal
  ok   event integrity: 14 events, unedited and in order
  ok   sealed once: one sealing event
  ok   seal matches certificate: the recorded seal is this certificate

No document was given to check. Pass a file as an argument and it will say whether
it is the document that was signed, the executed copy from this package, or neither.

Everything checked here holds.

Now break it

A checker that only ever says yes is not telling you anything, so the more useful half of this exercise is the second half. Open certificate.json, change one character of a signer's email address, save it, and run the verifier again. It exits non-zero and names what stopped matching.

Do the same to events.json — delete one event from the middle of the array. The chain is what makes that visible rather than merely suspicious: every event carries a hash covering the one before it, so removing one breaks every link after it.

That is the whole claim, and you have now tested it rather than read it.

What each file is for

File	What it is

|---|---|

certificate.json	Every fact the certificate asserts, machine-readable
events.json	The full hash-chained event trail
signed.pdf	The executed document itself
manifest.json	Every file above, with its size and SHA-256
verify.mjs	The checker, assembled from the platform's own hashing and chain code

verify.mjs is not in the manifest, deliberately: a verifier that vouched for itself would be vouching for nothing. It is checkable a different way — it is assembled from the same modules the platform runs, so what you are running is what we run.

You can also pass a document to check against the package:

node pactlyra-sample-evidence/verify.mjs pactlyra-sample-evidence some-file.pdf

It will tell you whether that file is the document that was signed, the executed copy from this package, or neither.

Last reviewed 2026-09-18. Pactlyra produces a detailed evidence record for every completed document. Electronic signature validity depends on your jurisdiction, the document type, and how the transaction is carried out; nothing here is legal advice.