Audit Log and Trace¶
Artifact — instantiates Declared Effect Boundary Enforcement
Records actual effect events in a durable form that can be inspected, explained, and reconciled.
Audit Log and Trace is the durable, append-only record of what an action actually did to shared state — who touched which surface, when, under whose declared authority, and (where it matters) the value before and after. Its defining trait is that it is pure observation: it neither authorizes, blocks, nor repairs anything. It makes the real effect surface legible after the fact, so a violation of the declared boundary can be found, named, and accounted for even when no one saw it happen. Where other mechanisms decide what may change, the audit log is the one that can say, later, what did.
Example¶
A retail bank runs a core payments service. During nightly reconciliation, a customer's balance is found to have moved without a matching posting. Nobody remembers touching it, and the visible endpoints all look read-only. The audit trail settles it. Every mutation of ledger state was written as its own immutable event: the acting service account, a millisecond timestamp, the endpoint invoked, the exact ledger row, the prior and new value, and the authority token that was presented. An engineer replays the trace for that account and finds the culprit — a "statement generation" job, advertised as read-only, that also decremented a promotional-fee counter on each run.
The log does not fix the discrepancy or stop the job. What it does is convert an unexplained anomaly into a precise, attributable fact: this job, this run, these rows, this much. That precision is what lets the team open a real incident instead of arguing about whether an incident happened.
How it works¶
- Append-only capture. Each effect is written once, never edited, so the record of the past cannot be quietly rewritten to match a preferred story.
- Effect-to-authority binding. Every entry ties the observed change to the declared contract in force at the time — actor, input, surface, and the authority claimed — so an effect can be judged against what was permitted.
- Trace correlation. A shared correlation ID stitches related events across services or steps into one causal chain, turning scattered writes into a reconstructable story.
- Tiered depth. Not every effect is recorded at the same fidelity; the record's granularity is dialed up for consequential surfaces and down for routine ones.
Tuning parameters¶
- Observation depth — from "an action occurred" to full before/after values, actor, and downstream propagation. Deeper records diagnose more but cost storage and raise privacy exposure.
- Retention window — how long traces are kept. Longer horizons support forensics and slow-burn reconciliation; shorter ones limit liability and leak surface.
- Tamper-evidence strength — a plain log versus a hash-chained one. Stronger integrity makes the record trustworthy enough to base accountability on, at some engineering cost.
- Capture rate — total capture versus sampling. Sampling saves volume but can miss the one rare event that mattered.
- Correlation granularity — how finely events are threaded into causal chains, trading reconstruction power against indexing overhead.
When it helps, and when it misleads¶
Its strength is accountability after the fact: incidents become diagnosable, changes become attributable, and disputes resolve on a record rather than on memory. It is often the cheapest first step, because it can be added without changing the action itself.
Its signature failure is monitoring without control — teams bolt on logging after an incident but never add prevention, authorization, or repair, so the next violation is merely better documented, not stopped. A second, subtler failure is that the record itself can become a new leak: a trace that captures sensitive before/after values turns an observability tool into a privacy exposure. The guarding discipline is to make the log feed enforcement and review rather than substitute for them, and to scrub or tier sensitive fields so the record stays trustworthy without becoming its own hazard.[1]
How it implements the components¶
effect_observability_record— its whole reason for existing: the durable, attributable account of what actually changed, tied to declared authority and time.effect_criticality_tier— capture depth and retention are set per tier, so high-consequence surfaces get full before/after forensics while routine ones get a thin footprint.
It does NOT implement mutation_gateway or rollback_or_compensation_path — recording an effect is not authorizing or repairing one; those belong to Transaction Boundary and Compensating Action Protocol.
Related¶
- Instantiates: Declared Effect Boundary Enforcement — supplies the observed-effect record the appraisal reconciles against the declared contract.
- Sibling mechanisms: Command–Query Separation · Compensating Action Protocol · Effect Contract Annotation · Effect Review Checklist · Immutable Data or Copy-on-Write · Permission Scope or Capability Token · Sandbox or Staging Execution · State Diff Test · Transaction Boundary
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Records actual effect events in a durable form that can be inspected, explained, and reconciled, 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 and Trace as 'Records actual effect events in a durable form that can be inspected, explained, and reconciled', 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: Single lineage
Present-day reach: Specialized
Rationale: Secure-computing practice developed append-only, hash-chained logs recording actors, timestamps, authority, and state effects.
Related originating lineages:
- Accounting & Auditing — Audit trails provide the older accountability model for reconstructing actual effects.
- Criminology & Forensic Studies — Forensic trace analysis uses ordered event evidence after a suspected boundary violation.
Review resolution: Computer science is the agreed primary lineage. Accounting and forensic practice materially motivate durable, inspectable event records, but logs and distributed traces are established observability artifacts rather than a synthesized mechanism.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Bruce Schneier and John Kelsey's design for secure audit logs (1999) hash-chains each entry to its predecessor so that tampering with any past record is detectable. It is the standard reference for making a trace trustworthy enough to enforce accountability on, rather than a log that could be quietly rewritten. registry ↩