Skip to content

Change Log and Audit Trail

Recordkeeping audit trail — instantiates Source-of-Truth Assignment

Preserves an append-only record of every change to authoritative state — who, when, why, under what right, and what it propagated to — so the source's history is accountable and reconstructable.

Change Log and Audit Trail records the history of the authoritative source, not its current value. Every mutation is captured as an ordered, tamper-evident entry — old value, new value, actor, time, the right it was made under, and what it propagated downstream. Its distinguishing purpose is accountability and reconstruction: it lets anyone answer what the authoritative value was at a past moment and how it got there, and it makes a bad change traceable and reversible. It decides nothing about truth; it is the memory that every dispute and rollback reads from.

Example

A bank's deposit rate card is authoritative and changes often. A customer disputes the rate they were quoted last month, and the question is precisely what the authoritative value was then and who set it. The change log holds the answer: an entry showing the rate moved from ≈4.1% to ≈3.9% on a specific date, made by a named treasury user, approved through the rate-change workflow, effective the next business day, and pushed to the pricing display and statement generator. The dispute is settled by reading the trail rather than by anyone's recollection — and when a fat-fingered rate slips through, the same trail is what lets the team find the offending edit and roll back to the prior version.

How it works

The mechanism captures each change to authoritative state as an append-only entry and never overwrites. Distinctively, it records not just the diff but the context: the actor, the justification, the right exercised, and the downstream propagation — the things a later reader needs to interpret why a value became authoritative. Entries are ordered and tamper-evident so the sequence can be trusted, and they double as a version history: replaying them reconstructs the authoritative state at any past point.

Tuning parameters

  • Capture granularity — log every field edit or only material changes. Fine granularity reconstructs perfectly but grows fast and buries signal.
  • Immutability strength — an append-only table versus a cryptographically chained or WORM store. Stronger tamper-evidence costs more but is what makes the trail trustworthy under challenge.
  • Reason requirement — force a justification on each change versus capturing only the mechanical before/after. Reasons make the history interpretable; requiring them adds friction.
  • Retention horizon — how long entries are kept, trading compliance and reconstructability against storage and privacy exposure.

When it helps, and when it misleads

Its strength is turning authoritative state into something accountable and reversible — it is the evidence base every other conflict mechanism appeals to, and without it "the source" is just a value nobody can defend. Its failure modes are quiet: a log that records what changed but not why gives thin assurance, and a log that can itself be edited gives false assurance — the appearance of an audit trail with none of the protection.[1] The classic misuse is mining the trail to assign blame rather than to reconstruct truth, which pushes people to make changes off the record. The discipline that guards against this is genuine immutability plus capturing intent, not just the diff.

How it implements the components

  • audit_trail — its core output: the ordered, tamper-evident record of who changed authoritative state, when, why, under what right, and with what downstream effect.
  • version_record — the same entries form a replayable history, so the authoritative state at any past moment can be reconstructed and rolled back to.

It does not decide who is *allowed to make a change (that is Access and Update Rights Matrix), route or resolve a live conflict (that is Conflict Resolution Workflow), or version code and content in a repository (that is Source-Control Main Branch).*

  • Instantiates: Source-of-Truth Assignment — it supplies the accountable history that keeps an assigned source defensible over time.
  • Sibling mechanisms: Access and Update Rights Matrix · Conflict Resolution Workflow · Source-Control Main Branch · System-of-Record Designation · Golden Record Consolidation · Synchronization Job · Master Data Management · Canonical Registry · Official Record Policy · Authoritative Policy Repository · Deprecation and Forwarding Notice

Notes

Its version_record overlaps Source-Control Main Branch by purpose but not by medium: this trail is the change history of authoritative business state (rates, statuses, records), while source control is the version history of code and content. A system may run both, and each is the audit of its own domain.

References

[1] "WORM" (write-once, read-many) storage and append-only, cryptographically chained logs are the standard means of making an audit trail tamper-evident. The property that matters is not that changes are recorded but that recorded entries cannot be silently altered after the fact. ↩