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.[n1] 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).
Also instantiates¶
Layered Record Accumulation — A different end than integrity investigation: preventing historical flattening, where a record's current snapshot erases the ordered layers of change that produced it. The Audit Log is the accumulating stratum of a record's formation history — each entry a sequenced layer carrying its actor, time, and circumstances — so a later reader can reconstruct not just whether a value was tampered with but in what order, by whom, and under what conditions the record became what it is. Its append-only discipline is exactly the layer-accumulation move: old states survive as interpretable strata rather than being overwritten by the latest value.
layer_record— each audit entry is a distinct layer capturing one change, event, or action, the basic unit that turns a final snapshot into readable history.timestamp_or_sequence_marker— the ordered timestamp places the layers in a trustworthy sequence of formation.change_context— the reason captured with each entry records the circumstances around a layer, keeping old entries from being misread as timeless facts.
Observability Instrumentation — Here the problem is control blindness: a hidden state — an account behaving anomalously, a spike in sensitive-record exports, a drift toward risky change patterns — that decision-makers cannot infer from available evidence. The Audit Log becomes a capture layer feeding state inference: its who-did-what event stream is a signal from which that hidden state can be read, provided the entries are interpreted against a baseline and wired to a response. This is forward-looking, unlike the primary facet's after-the-fact reconstruction — the log is instrumented and watched so an anomaly surfaces as an actionable signal, not just investigated once it is already known.
telemetry_signal— the log's event stream is the observable output from which hidden state such as misuse, anomalous access, or drift is inferred.baseline_and_threshold— expected-behavior baselines over log events separate routine activity from the deviations worth acting on.decision_link— the log counts as observability only when a threshold crossing is connected to a response — an alert, a review, an escalation — rather than merely retained for compliance.
Related¶
- 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
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: 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, making its operative form a durable account of actual events, decisions, or transitions whose value depends on history or provenance.
Independent corroboration: The frozen evidence defines Audit Log as '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', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Specialized
Rationale: Computer security and database systems developed append-only attributable event logs for integrity and incident reconstruction.
Related originating lineages:
- Accounting & Auditing — Accounting's audit trail lineage supplies attributable records of consequential transactions.
- Criminology & Forensic Studies — Digital forensics uses tamper-evident logs to reconstruct events and establish non-repudiation.
- Security Studies & Intelligence Analysis — Security operations use logs for forensic investigation and incident reconstruction.
Review resolution: Computer science is the agreed primary lineage for append-only attributable event logs. Accounting controls, forensic reconstruction, and security monitoring independently shaped audit-log requirements, but the mechanism remains a specialized computing artifact rather than an Encyclopedia synthesis.
Review outcome: Reconciled after independent review; high confidence.
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.
[n1] 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. ↩