E-signatures · Glossary

What evidence does an electronic signature produce?

An electronic signature produces a set of records rather than a single artefact: the identity check the signer passed, the network address and browser behind each action, the moment consent was accepted and to which wording, hashes of the document and of the signature image, and a sequenced log of everything that happened.

People picture a signature as one mark on one page, so they picture the proof as one thing too. In a dispute, the mark is rarely what is argued about, and the surrounding record is what settles it.

Indunil Asanka · Co-founder

5 min read · Published 12 September 2026

Each item of evidence, where it lives and what it settles
Evidence item	Where it is held	What it answers
Identity check that was passed	Certificate of completion, signer block	Whether the signer had the inbox only, or a code as well
Network address and browser string	Audit trail event, address repeated on the certificate	Where the action came from and on what
Consent timestamp and version	Certificate of completion, signer block	That electronic records were accepted before signing, and under which wording
Document hash at signing	Certificate of completion, signer block	That the file in evidence is the file the signer saw
Signature image hash	Certificate of completion, signer block	That the stored mark is the mark applied
Sequenced events in a hash chain	Audit trail	That nothing was inserted, reordered or rewritten
Certification algorithm	Certificate of completion, envelope block	Whether a trusted time source was involved or only the server clock

The bundle, and why it is a bundle

Ink works as proof because handwriting is hard to copy and paper is hard to change without leaving marks. Neither of those properties survives the jump to a screen, so an electronic process replaces one strong artefact with many weak ones that only add up together. The mark itself proves almost nothing. What carries the weight is the chain around it: an invitation sent to a named address, a check that address holder passed, a moment of consent, a document fixed by its hash, an action recorded with its origin, and a completed file whose integrity a reader can test. Pull any single item out and the story has a gap. Keep them together and the gaps close, which is why the evidence is produced as a package rather than as a single certificate.

What the certificate of completion sets out

The certificate is a separate document, produced automatically and offered as its own download. It opens with an envelope section: the identifier, when it was sent and completed, how many signers there were, the certification algorithm, the hash of the document as it was sent and the hash of the fully signed file. Then one block per signer, carrying the verification method in plain words, the moment they signed, the address the action came from, when they accepted consent and to which version, the document hash at the time they signed, and the hash of their signature image. Last comes the event log, printing every entry with its sequence number, a timestamp in coordinated universal time, a readable label and the signer's email. A two signer envelope usually fits on one page.

What the trail adds that the certificate does not

The audit trail is the longer record, held in the system rather than on the page, and it carries eighteen kinds of event covering the whole life of a request rather than only the signing. Each entry stores its sequence number, the time, the type, the recipient it belongs to, the network address, the browser string and any metadata that event needed. Each entry also stores a hash computed over its own contents together with the hash of the entry before it, so the entries form a chain. Rewriting an old row changes its hash, which breaks every hash after it, and a verification pass reports either that the chain holds or the exact sequence number where it stops holding.

Three places the record is thinner than people assume

Downloads are not recorded. Nothing is written when a completed file is fetched, so there is no way to show from the trail who took a copy and when. The address printed against a signer is taken from a request header, so it is as reliable as the network path in front of it and no more. And the two hashes printed on the certificate describe the file as it was sent and the stamped file before certification, so neither of them equals a hash taken of the completed download. A reader who compares the two will find a mismatch and reasonably conclude something is wrong, when nothing is. Say what each hash covers rather than inviting the comparison.

Producing it when somebody asks

The moment to think about evidence is before it is needed, because the useful version is the one already filed. When an envelope completes, the certified file goes out by email to every recipient and to the sender, and the certificate is available beside it. File both in the same place as the contract, not in the mailbox of whoever happened to send it. Where a matter is likely to be contested, note at the time which identity check each signer used, because that single fact does more to settle an argument later than any other item in the bundle. There is no report to export from the envelope list, so the per envelope certificate is the artefact worth keeping.

Questions people ask

Is the certificate the same thing as the signed PDF?

No. They are two files. The signed PDF is the agreement with every mark stamped onto it and a cryptographic signature applied over the whole thing. The certificate is a separate summary of who did what, when, from where and with which check. There is an option to append the certificate pages into the signed file as well, and it is off unless somebody turns it on.

Does the evidence show which device somebody used?

It records the browser string the device sent, which usually names the browser, its version and the operating system family. That is a weak identifier and a useful one: it will not tell you whose laptop it was, but a signature applied from a phone when the signer insists they were at a desk is at least a question worth asking.

Can a signer keep their own copy of the evidence?

Yes, and they get one without asking. The completion email goes to every recipient as well as the sender, with the certified file attached, so both sides hold the same artefact rather than one side holding the record and the other holding a promise. That symmetry is worth more in a dispute than anything either party could assemble afterwards.

What evidence exists if nobody ever signs?

Quite a lot. An envelope that is declined carries the decline with its reason and notifies the sender, one that lapses carries an expiry entry written by the nightly sweep, and one that is withdrawn carries that too. Attempted signing that failed an identity check is recorded as a failed attempt, which is often the interesting part of an unfinished request.

Is a screenshot of the signing screen worth anything?

Very little on its own. A screenshot shows what one person says they saw, is trivial to fake and carries no link to the file that was signed. If a moment genuinely needs capturing, the useful record is the document hash at signing, because that ties the exact bytes the signer was shown to the copy sitting in the file today.

How long do the intermediate versions stay available?

Each signature writes a new working copy rather than overwriting the previous one, and the file as originally uploaded is never replaced, so the state of the document after each signer can still be retrieved. The completed copy is stored under a name derived from its own content, which means the name changes if the bytes ever do.

Make one with e-signatures

The button opens the generator with this use case already described. Change the wording to match your own.

Send a document for signing

Sources

Written and checked by the OneCraft team. Last checked 12 September 2026.