Skip to content

Audit trail

A signature is only as good as the evidence that it happened. Every document carries a history of what occurred, when, and to whom — recorded by the platform rather than entered by anyone.

The history shows these fourteen kinds of event:

Event Recorded as
Document was created {name} ({email}) criou o documento.
Added new recipient Each signer or cc recipient added, with how they were asked to sign
Document is processing The document is being sealed before sending
Signer was notified An invitation to sign was sent
Document signed A signer completed their signature
Document completed All steps are completed and the document has been successfully signed.
Document was rejected {name} ({email}) rejeitou assinar o documento.
Owner was notified The sender was told about a refusal
Signer was notified Other signers were told about a refusal
Document was cancelled {name} ({email}) cancelou o documento.
Signer was notified Signers were told about the cancellation
Document has expired O documento {name} expirou em {date}
A signer’s turn came up {name} ({email}) was activated by the signing order and can now sign.
Signer promoted with their own round {name} ({email}) now signs in a round of their own.

Notice how much of the trail is about notification, not just signing. The record shows not only that someone signed, but that they were properly asked — which is the part that matters if a signature is ever disputed.

When someone declines, the reason they gave is kept alongside the event under Motive.

Every event is recorded with a hash — a SHA-256 fingerprint — computed over the hash of the same document’s previous event, the document, the recipient, the event type, the status, the event data and the instant it was recorded. A document’s first event has no predecessor; every later one is tied to the one before it.

That is what makes the history verifiable:

  • Altering a line changes the hash it should have, and it no longer matches what was stored.
  • Deleting or inserting a line breaks the next line’s link to the previous hash.

Verification rebuilds the chain from the first event to the last and stops at the first line that does not match. It runs when the Completion Report is generated, and the result goes into the sealed report: the verdict, the number of verified entries and the hash of the last event (Chain root hash (SHA-256)).

The chain uses no secret key: someone able to write to the database who recomputed every later line would get a consistent chain. It is the last event’s hash, fixed in the sealed report, that would stop matching.

An older document may have events recorded without a hash. Verification skips them; if none of the document’s events has a hash, the report says the chain is not verifiable rather than inventing a verdict.

Open a document and go to its audit view. Alongside the event history you get the recipient list, and the option to copy it or export the history.

A document’s audit view: participants, details and the timeline.

The history can be downloaded as an Excel file, so it can be attached to a case file or kept outside the platform.