Logging

Prime #

970

Origin domain

Computer Science & Software Engineering

Subdomain

software observability → Computer Science & Software Engineering

Core Idea

A system records its own events as they occur — append-only, timestamped, self-describing — so that an actor not present at the original moment can inspect the record later. The substrate-independent move is record now, interpret later.

How would you explain it like I'm…

The Never-Erase Diary

Imagine you keep a little diary and every time something happens you write it down with the time, like 'lunch at noon, dog barked at 1.' You never erase the old lines, you only add new ones at the bottom. Later, someone who wasn't there can read your diary and know exactly what happened and when.

The Captain's Logbook

Logging means a system writes down its own events as they occur, like a ship's captain jotting the time and weather in a logbook. Each note gets a timestamp and enough detail to make sense later, even to someone who wasn't around. New notes are always added to the end, and old ones are never overwritten. The point is that the person who reads the log is usually different from the one who wrote it, reading at a different time for a different reason.

Record Now, Read Later

Logging is the discipline of a system recording its own events at the moment they occur, in order, each carrying enough context to be understood out of its moment. It rests on four commitments: writes are append-only (you add, you never overwrite), events keep their time-order, each event describes itself, and the reader is usually a different person reading at a different time. That last part — record now, interpret later — is what makes it a log rather than just live monitoring or the system's current state. A monitor shows you the present; a log preserves the past so a later inspector can reconstruct it. The writer commits to saving events it may have no use for yet, betting that someone eventually will.

 

Logging is a structural pattern: a system records its own events as they occur, to a medium designed not to be overwritten, so the history becomes externally legible after the fact. Four commitments define it — append-only writes, temporal ordering, contextual self-description (each event carries enough metadata to be intelligible out of context), and deferred reading (the consumer is usually not the writer, reading later and for a different purpose). The defining move is event-time persistence with self-description and append discipline, which is exactly what separates a log from both the live running state and a real-time monitor. Its leverage is retrospective: debugging, audit, replay, accountability, and forensics are all activities that can't be done in real time and would be impossible without a faithful ordered record. The writer commits to recording events it may currently have no use for, on the bet that some future inspector will need them. The pattern carries a 'framed' character because logs are produced for human or institutional inspection — ledgers, charts, dockets all carry accountability weight — but underneath, the skeleton of append-only event-time recording with deferred reading is substrate-neutral.

Broad Use

• Software: application logs, distributed traces, write-ahead logs, and audit trails — the canonical home.
• Science: the signed lab notebook, a timestamped append-only record for replicability.
• Law: court records, chains-of-custody, and minutes, with penalties enforcing append discipline.
• Medicine: the medical chart and medication-administration record, on which continuity of care depends.
• Finance: double-entry bookkeeping and the general ledger — the canonical pre-digital log.
• Aviation: the flight data recorder, where after-incident inspection is the consumer.
• Natural archives: tree rings, ice cores, and sedimentary strata accreting append-only entries read off later.

Clarity

Separates the act of recording from the act of inspecting, exposing the error of "we'll record what we need when we realise we need it" — by then the event has passed — and drawing a sharp line between the log (what happened) and current state (what is true now).

Manages Complexity

Compresses design and governance to a small decision set — what events to log, what context each carries, how long to retain, who may read — and collapses whole industries of after-the-fact inspection into one shape: retrospective inspection of an event-time log.

Abstract Reasoning

Supports the log-determinism inference: if behaviour is a function only of the log plus deterministic processing, replaying the log reproduces the behaviour — the justification for event sourcing, blockchain validation, and double-entry audit alike.

Knowledge Transfer

• Accounting to databases: the append-only ledger and its trustworthiness argument transfer verbatim to event-sourcing and write-ahead logging.
• Aviation to medicine: the record-always-review-on-incident model ported into operating-theatre recording and incident review.
• Engineering to geology: ice cores and tree rings are read using the engineered-log vocabulary of "log resolution" and "missing entries."

Example

A database write-ahead log records each transaction's change before applying it, append-only and ordered; after a crash the recovery process — a deferred inspector, not the original transaction — replays committed entries to reconstruct the correct state.

Relationships to Other Primes

Parents (1) — more general patterns this builds on

• Logging presupposes, typical Observability — Logging is the append-only, event-time, deferred-reading mechanism that makes a system's internal history externally inspectable — it presupposes/serves observability (infer internal state externally), as its retrospective record-now-interpret-later instance.

Path to root: Logging → Observability

Not to Be Confused With

• Logging is not Monitoring because the former is append-only event-time recording for a deferred inspector, whereas monitoring observes current state and alerts so someone can act now.
• Logging is not Provenance because the former is a chronological record of events, whereas provenance is the derivation lineage of an artifact answering "how did this come to be?"
• Logging is not Traceability because the former is a time-ordered event record, whereas traceability is the link structure between related items that a log may support but is not.