Append-only log

An append-only log preserves a sequence of entries by adding later records instead of mutating earlier ones in normal use. That structure can make changes observable and support reconstruction of a previous state. It says little on its own about the truth of an entry, the completeness of captured activity, or whether privileged administrators can alter storage. Those properties depend on controls, retention, and independent verification beyond the append operation.

Useful log entries identify an actor or process, a timestamp with defined semantics, an action, and the affected object or assertion. Corrections need explicit links to the entries they supersede. Consumers must know whether order is total or only local to a stream, and whether duplicate delivery is possible. Operational logs may be compacted or expired under a retention policy, so an 'append-only' label should not be mistaken for indefinite preservation.

The pattern helps an organization show how its recorded understanding changed rather than presenting only the latest value. It can support an audit trail or an event-sourced view, but those are different concepts: the former asks what activity is accountable, while the latter derives state from events. A retained source copy and chain of custody are still needed when a reviewer must inspect the evidence behind an entry.

An entry should record who or what acted, what was done, to what, when and with what result, in enough detail to reconstruct the action but without unnecessary sensitive content. The NIST Guide to Computer Security Log Management, SP 800-92 discusses what to log, how to protect logs from alteration, and how to manage their volume and retention. The Wikipedia article on append-only gives the general computing background.

Logs grow. Plan for compaction and archiving without breaking verifiability: archive complete segments with their hashes, keep the roots, and record the archive as a log entry. Plan for erasure obligations by keeping personal data outside the log or encrypted under keys that can be destroyed. Plan for clock and ordering: entries should have a sequence number as well as a timestamp, since timestamps from different machines may not agree.

Ask who holds privileges that could alter or delete entries. Recompute the hash chain on a sample and compare to independently held roots. Ask where the roots are kept and who can alter them. Ask how the log handles archiving, erasure requests and clock differences. Test detection by altering a copy of a log segment and confirming that verification fails.