Audit events are written once.The database refuses to change them.
Two triggers on the audit table raise an exception on any update or delete, and those rights are revoked from every role OfferFlow runs as — including the service role that writes the events in the first place.
The events a document can collect
These are the event types OfferFlow records. When an event is captured, it carries the server timestamp from the request or database action.
| Event | When it is written |
|---|---|
| Document uploaded | You add a PDF to your account. |
| Document sent | Signing links are issued. Recorded inside the same transaction that issues them, with the number of signers. |
| Signing link opened | A signer's link resolves successfully in their browser. |
| Document viewed | The PDF itself is served to that signer. |
| E-sign disclosure acknowledged | The signer accepts the electronic-signing disclosure before reaching the pages, where that acknowledgement is captured. |
| Electronic consent given | The signer confirms the final submission. Stores the version and the exact consent wording they were shown. |
| Signature submitted | A signer's submission is accepted. Records whether the signature was typed or drawn. |
| Reminder sent | You resend to outstanding signers. Records how many went out and how many failed. |
| Signer email corrected | You fix a bounced address, which also rotates that signer's link. |
| Processing | The last signature has landed and the signatures are being stamped into the PDF. Written by the database, not the application. |
| Document completed | The completed state is committed. This is the row the final PDF hash is anchored to. |
| Document voided | You withdraw a sent document. Nothing already recorded is removed. |
What travels with every row
Five fields on every row. Two of them are empty when the event came from the database rather than from somebody's browser.
- The time it was written, in UTC
- Set by the database when the row is inserted, not by the browser that triggered it and not by a value the client can supply.
- Who it belongs to
- A signer, an account user, or the system. Signers and users are resolved to a name and email address when the trail is read, so the row itself stays a reference rather than a copy.
- The IP address of the request
- Stored as it arrived. Rows the database writes itself — stamping and completion — have no request behind them, so they carry none. It places a request, not a person: see the limits below.
- The device string the browser sent
- Kept in full on the row and shortened to a readable device description on the certificate. Empty for the same database-written rows.
- A short, allowlisted set of extra fields
- Each event type accepts only its own named fields — a consent version, a signature method, a step number, a signer count. Anything else is dropped, and any value that looks like an email address is rejected outright.
Four separate reasons a recorded event stays recorded
Immutability here is a property of the database, not a rule the application promises to follow.
Two triggers that reject the statement
A trigger on UPDATE and a trigger on DELETE raise the exception 'audit_events is append-only' for every row, unconditionally. There is no condition under which they let the statement through.
The rights are revoked as well
UPDATE, DELETE and TRUNCATE are revoked from the browser roles and from the service role. The role that writes audit events cannot change one afterwards.
The browser cannot write one either
INSERT is revoked from both browser roles and backed by a policy that refuses every client insert, so events can only originate from the server paths that produce them.
Deleting your account will not clear them
Account deletion is refused outright while any of your documents still carries recorded events. Erasing the evidence is not something the product offers as a feature.
The final PDF is fingerprinted into the same table
At completion a SHA-256 hash of the stamped PDF is anchored onto the completion event itself. The database refuses to write that event at all unless the hash is present and well formed, and the row then falls under the same append-only rules as every other — so the fingerprint cannot be quietly updated later to match a different file.
What the Certificate of Completion prints
One PDF, generated automatically at completion. It opens with a summary block and continues with the event log.
On the summary page
- Document title and status
- The document as it was named, and the state it completed in.
- Completed at
- The completion timestamp, in UTC.
- Identity verification
- Printed as what it actually is: access through a tokenized email link. The certificate does not claim more than the product does.
- Final PDF SHA-256
- The full 64-character hash of the signed file, printed in monospace across two lines so it can be compared by eye.
- Final PDF path and reference
- The stored location of the signed file and a short document reference, for matching a certificate to a document later.
- Consent line
- The timestamp at which electronic-signing consent was recorded, or an explicit note that it was not recorded.
In the event log below it
- Time (UTC)
- When the event was written, oldest first.
- Action
- The event in plain words — Sent, Session Started, Viewed, E-Sign Consent, Signed, Reminder Sent, Completed — with the signature method in brackets where there is one.
- User
- The resolved actor name and email address, plus the request IP where captured.
- Device
- A readable description derived from the browser's device string.
The certificate exists before the document is marked complete
The timeline is built, rendered and uploaded first. Only then is the completed state committed, in the same database call that stores the signed PDF path, the hash and the certificate path. If the certificate cannot be produced the completion is rolled back — so a completed OfferFlow document without a certificate is not a state the product can reach.
Three ways to reach the record
All three read the same events. None of them regenerates history.
- The dashboard, for as long as the document is there
- Download the signed PDF and the certificate from the document's actions. The certificate is owner-only: the request is checked against your account and against that exact document before a link is issued.
- The completion email
- OfferFlow sends completion emails with download access to signers and the owner. The links are time-limited, so the dashboard is the durable copy.
- The trail inside the app
- Open a document's events directly from its actions menu to read the timeline without opening a PDF. It shows the documents you own and nothing else.
What this record does not prove
An audit trail is evidence about a process. Read plainly, here is where its usefulness stops.
- It does not prove who was holding the device
- Attribution rests on control of the email address the link was sent to. There is no identity-document check, no one-time passcode and no multi-factor step, and the certificate says so on its own summary page.
- An IP address is not a person or a place
- It is recorded exactly as the request presented it. Shared networks, mobile carriers and VPNs all make it a weak locator, and OfferFlow does not present it as more than a recorded request detail.
- The disclosure acknowledgement is recorded when it is captured
- It is written as its own event when the signer accepts it, but it is not a hard prerequisite the signing path fails closed on. Read its presence on a certificate as evidence, not as a guarantee it exists on every document.
- These are standard electronic signatures
- Not qualified signatures, not PKI-backed digital signatures, not a witnessed or notarized execution. The hash proves the file has not changed since completion; it is not a signing certificate.
- It is not a legal opinion
- Whether a particular document is validly executed depends on its type, your jurisdiction and the surrounding facts. OfferFlow produces the evidence and makes no claim about the outcome.
The wider positioning — which legal frameworks this kind of workflow is designed around, and where OfferFlow keeps its wording careful — is on the trust page. What produces these events is on how it works.
See the feature list