Audit Log¶

Audit record — instantiates Data Integrity Preservation

Keeps an append-only, attributable record of every action on protected data — who, when, and what changed — so integrity events can be investigated and reconstructed after the fact.

Audit Log is the memory the rest of the integrity machinery reads from. Every consequential touch of protected data — a create, edit, approval, deletion, export, restore — is captured as an ordered, tamper-evident entry carrying actor, timestamp, before/after value, and, where it matters, the reason. Its distinguishing job is not to prevent a bad change or to decide whether a value is correct, but to make the history attributable and inspectable so that when an anomaly surfaces or two records disagree, an investigator can answer who changed this, when, and to what — and reconstruct the sequence of events that produced the current state. It turns "the data looks wrong" into a traceable trail rather than a mystery.

Example¶

A hospital's electronic health record shows a patient's recorded allergy list changed overnight, and a near-miss during medication ordering flags it. The question is not yet which value is right but what happened. The audit log answers: an entry shows the penicillin-allergy flag was cleared at 02:14 by a specific pharmacy-tech account, during a bulk import from an outside clinic's feed, overwriting a nurse-entered value from the prior afternoon. That single trail localizes the problem — it was an import overwrite, not a clinician decision — and hands the reconciliation team exactly the actor, time, and source they need to correct the record and tighten the import. Without the log, the same investigation is a guessing game across half a dozen accounts.

How it works¶

The mechanism appends and never overwrites. Each entry is written as an event, ordered so the sequence can be trusted, and made tamper-evident (append-only tables, hash-chaining, or write-once storage) so the record of what happened cannot itself be quietly rewritten. What distinguishes a useful audit log from a bare event dump is that it captures enough context to interpret intent — the actor, the operation, the old and new values, and ideally the justification — so a later reader can tell an authorized correction from a suspect one. It is deliberately passive: it records, and leaves detection, judgement, and repair to other mechanisms that read it.

Tuning parameters¶

Capture granularity — every field-level edit versus only material changes. Fine granularity reconstructs perfectly but grows fast and buries the signal an investigator actually needs.
Tamper-evidence strength — a plain append-only table, a cryptographically chained log, or WORM storage. Stronger guarantees cost more but are what let the log stand up under challenge.
Reason capture — whether each change must carry a justification or only the mechanical diff. Reasons make the history interpretable; requiring them adds friction at write time.
Retention horizon — how long entries are kept, trading investigability and compliance against storage cost and privacy exposure.

When it helps, and when it misleads¶

Its strength is that it is the evidence base every other integrity mechanism appeals to: anomaly monitoring, reconciliation, and recovery all become far more powerful when there is a trustworthy record of what happened. It also creates accountability — changes made in the open are made more carefully. Its failure modes are quiet. A log that records what changed but not why gives thin assurance; a log that can itself be edited gives false assurance — the appearance of an audit trail with none of the protection, so non-repudiation quietly fails.^[1] The classic misuse is mining it to assign blame rather than to reconstruct truth, which teaches people to make changes off the record. The discipline that guards against this is genuine tamper-evidence plus capturing intent, and wiring the log to investigation rather than letting it rot as a passive paper trail.

How it implements the components¶

integrity_evidence_log — its core output: the ordered, tamper-evident record of integrity-relevant events that investigations, reconciliations, and audits read.
provenance_record — the same entries preserve the attributable change history of a record — who set each value and when — one facet of where a value came from.

It does not define what a valid value is (that is Data Validation Schema), restrict who may make a change (that is Access Control Enforcement), or detect and repair the discrepancies it helps investigate (that is Integrity Anomaly Monitoring and Reconciliation Workflow).

Instantiates: Data Integrity Preservation — it supplies the accountable event history the rest of the pattern relies on to investigate and reconstruct.
Sibling mechanisms: Integrity Anomaly Monitoring · Reconciliation Workflow · Access Control Enforcement · Data Lineage Capture · Data Validation Schema · Checksum or Hash Validation · Referential Integrity Constraint · Transactional Write Control · Backup and Restore Verification · Source-of-Truth Registry

Notes¶

An audit log records actor-level events on a record — who did what, when. It is complementary to Data Lineage Capture, which maps how a value flowed through transformations and joins across systems. One answers "who touched this record," the other "where did this number come from"; an investigation of a suspect value usually needs both.

References¶

[1] Non-repudiation — the property that a party cannot plausibly deny having performed a recorded action — depends entirely on the log being tamper-evident. Append-only, hash-chained, or write-once (WORM) storage is what supplies it; a log stored where its own entries can be edited provides accountability in appearance only. ↩