Audit trail & data integrity
The record is made as the work happens.
Every change to a governed record produces an audit event. Not because someone remembered to log it, but because the system has no other way to write. A change that produced no audit event would fail the build before it ever reached you.
How it works
- Each event carries the acting person, the time, the action, a structured reason, and the value before and after
- The acting person is recorded by the server from the signed-in session, so attribution cannot be set by whatever is calling the system
- Time is applied by the server. A client cannot backdate anything
- The trail is append-only. A correction is a new event that keeps the original readable
- Automated actions are attributed to the process that made them, and are distinguishable from a person's work
- Filter by record, person, date, action or reason, and export the result
This is what makes the ALCOA+ data-integrity attributes a property of the system rather than a policy people have to follow.
See it in a working system.
We will walk a live workflow and show this capability behind the steps it governs.