How the Audit Chain Works
An audit log that can be edited proves nothing. The audit chain is what turns the log from a record into evidence.
Where to find it
Architect Panel → Activity:
- Audit Chain — the chain head and verification state for each datastore
- Activity Log — the entries the chain is built over
Architect Panel → Automation:
- Tasks — Audit Chain Sealing, every 5 minutes
The problem it solves
Anybody with sufficient database access can change a row. If the audit log is just another table, then somebody who can alter a record can alter the entry recording that they altered it — and the log's account of events becomes exactly as trustworthy as the access controls around it.
That is a weak position to be in when the log is the thing you are relying on to demonstrate what happened.
How chaining works
Each audit entry carries:
- A row hash — a fingerprint of the entry's own content.
- A sequence number — its position in the chain for that datastore.
- The previous entry's hash.
- A chain hash — computed from this entry and the one before it.
- A sealed timestamp.
Because each entry's hash incorporates the previous entry's, the entries form a chain in which every link depends on all the links before it.
Why that makes tampering detectable
Change the content of any historical entry and its row hash no longer matches. That breaks the chain hash of the entry after it, and every entry after that.
Delete an entry and the sequence has a gap and the following entry's previous-hash points at something that is no longer there.
Neither can be quietly repaired without recomputing every subsequent entry — and the sealed head, recorded separately, will still disagree.
Sealing
The Audit Chain Sealing task runs every five minutes and advances the sealed head for each datastore, recording the current sequence number and chain hash.
Sealing is what fixes history in place. Once a range of entries is sealed, altering any of them contradicts a hash recorded at a known time, so the window in which undetected tampering is even theoretically possible is the few minutes since the last seal.
The task ships disabled. Enable it under Automation → Tasks — an unsealed chain still detects internal inconsistency, but it loses the independent timestamped anchor, which is most of the value.
It is evidence, not prevention
Worth being precise about: the chain does not stop anybody from changing the database. It makes the change detectable.
That is the appropriate goal. Prevention is the job of access control; the chain's job is to ensure that if prevention failed, you can demonstrate it — and to remove the argument that the log might simply have been edited.
Per datastore
Each datastore has its own chain and its own head, so a problem in one is contained and identifiable rather than casting doubt over everything.
Worked example
An organisation with a regulatory obligation to evidence its record-keeping enables sealing at go-live. Two years later, asked to demonstrate that a set of case records has not been retrospectively altered, they show a verified chain over the relevant datastore with a continuous sealed history — which is a different quality of answer from asserting that nobody would have done so.
Recommendations
- Enable the sealing task at go-live, not when you first need it.
- Understand it as detection, and keep access control doing the prevention.
- Do not modify audit tables directly, for any reason — a legitimate correction still breaks the chain.
- Record when sealing was enabled; it bounds the period you can evidence.