Every line in an audit trail, and what each one does not prove

Search for an electronic signature audit trail and you will find a dozen pages listing what gets captured. You will find almost nothing about what those captures are worth.

That gap is not an accident. The second list is bad for a sales page and good for anybody who might one day have to rely on the record. This is the second list.

Every event on an envelope

closeit.fast writes an entry the moment each of these occurs. There is no batching, no reconstruction and no edit path, for you or for us.

Before it is sent

• Envelope created — the envelope exists and belongs to an account.
• Document uploaded — a file has been attached and its page count established.
• Document replaced — the file was swapped for another before sending.
• Document removed — the file was detached.

Those middle two matter more than they look. A trail that only records the document that ended up being signed cannot tell you whether it was the third version. This one can.

In flight

• Sent for signature — invitations dispatched, tokens issued.
• Invitation resent — a reminder went out.
• Next signer notified — on a sequential envelope, a stage completed and released the following one.
• Email address verified — control of the invited address was demonstrated.
• Document viewed — the envelope was opened.
• Consented to electronic signing — the recipient agreed, as a discrete step, before any field became signable.

How it ends

• Signature completed — fields filled and submitted.
• Signing declined — with the reason the signer gave.
• Envelope voided — the sender killed it; every outstanding link stops working on the next request.
• All signatures collected — the envelope completes, the certificate is generated and appended, the file is sealed.

The four fields on every entry

Regardless of which event it is, each line carries the same four things.

1. Actor. Who caused it, by name and email address where one is known.
2. IP address. The address the request arrived from.
3. User agent. The browser and operating system that made the request.
4. Timestamp. UTC, written when the event happened.

That fourth one has a detail worth stating plainly, because it is the difference between a record and a decoration: the timestamp comes from the server, not from the signer's device. A device clock is set by its owner and can be changed in about four seconds. A server clock cannot be reached by either party to the agreement. If a trail is taking times from the client, it is recording a claim, not a fact.

Now the part nobody publishes

Here is what each of those four fields does not establish.

An IP address is not a person

It identifies a network endpoint, usually resolving to an internet provider and a metropolitan area. It does not identify a human being, a household or a device. Any VPN changes it deliberately, most mobile networks change it incidentally, and a shared office gives fifty people the same one.

What it is genuinely good for is consistency. A trail where the view, the consent and the signature all arrived from the same address over eleven minutes tells a coherent story. One where they arrive from three continents in ninety seconds tells a different one. The value is in the pattern, not the number.

Control of an inbox is not identity

Verifying an email address proves that whoever acted could read mail sent to it. That is meaningful — it is the same assumption every password reset in the world rests on — and it is not proof of who somebody is.

We verify control of an address. We do not verify a passport. If your situation genuinely needs proof of identity rather than proof of access, it needs an identity provider in front of the signing step, and we will tell you that rather than let the audit trail imply otherwise.

A user agent is self-reported

The browser tells the server what it is, and the browser can say whatever it likes. It is corroborating detail, useful when it agrees with everything else and near worthless on its own.

The hash covers the file, and only the file

When the last signature lands, the whole trail is rendered into a certificate of completion, appended to the document as its final page, and the resulting PDF is hashed with SHA-256.

That digest proves one thing with real force: the bytes have not changed since sealing. It is tamper-evident, which is not the same word as tamper-proof, and the distinction is not pedantry. Nothing stops somebody altering the file. The hash guarantees that if they do, it stops matching.

What the digest says nothing about: who signed, whether they meant to, whether they had authority to bind their company, or whether the terms are enforceable. It is a statement about a file, not about an agreement.

Why publish the weaknesses

Because they are discoverable, and because the moment they matter is the worst possible moment to discover them.

If you are ever relying on one of these records, somebody on the other side will be looking for exactly the gaps above. Finding them in an article we wrote is survivable. Finding them after a vendor implied the trail was airtight is not.

A record is worth what its weakest claim is worth. Knowing which claim that is beforehand is most of the value.

Taken together, though, the picture is strong, and stronger than the paper alternative by a distance. A wet signature on a printed page carries no metadata at all. No time, no address, no sequence, no evidence the signer ever saw page four. Establishing that it is genuine means retaining a handwriting expert and arguing about loops.

Set against that, a trail that records fourteen event types, four attributes each, on a server clock, sealed with a recomputable digest, is not a weaker form of evidence. It is a considerably better one. It just has edges, and you deserve to know where they are.

Every envelope produces this, including on the free tier. If you want to see the shape of it rather than read about it, send yourself a document and read the trail it writes.