Most business software can tell you what a record says now. Fewer can show it says what it said on the day it was signed. When a form is an agreement, a consent or an inspection, that difference starts to matter.
Why a database row isn’t evidence
Anyone with enough access can change a row, and an audit log kept in the same database can be changed along with it. So we treat each form response as something to seal, not just something to store.
The seal
When someone submits a form, we write down everything about that event in one exact format: the answers, the form’s version, the time, and the device details. We then calculate a SHA-256 fingerprint of those bytes. Change one character, and the fingerprint no longer matches. That fingerprint is the seal.
The chain
A seal on its own only protects one record, and someone could still delete it. So each event also includes the seal of the event before it on that form. Removing or reordering one breaks the chain, and the break can be seen. Notes, correction requests, signatures and reminders go into the same chain.
Corrections are added, never written over. If an answer changes, the new version points to the seal of the one it replaces, and the original stays.
The signed PDF
Each response revision also becomes a PDF with an audit page. The sealed data is embedded inside it, and the file is digitally signed. The person who signed can keep that file. It doesn’t depend on anyone’s account, and they can check it later.
Proof of time, from outside
If we control the clock, then the date on a record only means what we say it means. So we also request timestamps from independent public services: an RFC 3161 timestamp authority, and OpenTimestamps, which anchors to the Bitcoin blockchain. Only the fingerprint leaves our system, never the answers. These services are best effort, so one being down never stops a response from being sealed, and the proof is added afterwards.
Checking it
Anyone can check a sealed record on a public page, without seeing its answers. The check confirms that the PDF signature covers the whole file, that the embedded data matches the seal, that a sealed record with that seal exists, that its link in the chain is intact, and whether a later revision has replaced it.
What this doesn’t prove
- It shows the record hasn’t changed. It doesn’t show that what someone typed was true.
- These are electronic signatures with an audit trail, not qualified signatures under schemes such as the EU’s eIDAS.
- Whether this is enough for your situation is a legal question, so have someone qualified confirm it for your use and jurisdiction.
Should you build this?
Probably only for records that someone may later dispute. For those, the idea is simple and the tools are open standards: a fingerprint, a chain, a signature and an outside clock. For everything else, a good audit log is usually enough.