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.

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.