Log (Change History)

When something is changed in a computer system, the old version is usually lost. A log prevents this: it is a continuous list of all changes that the system itself writes down. An entry typically records four things: the time, the acting person or program, the affected object, and the type of change. You can think of it like a school’s class register, except that no one fills it in by hand and no one is allowed to tear a page out again. The technical term for this is often log or audit trail. The edit history of an online document is also a log in this sense.

Why no one trusts a system without an audit trail

Without a log, a claim cannot be verified. If a bank says a transfer amount was never altered, that is just a statement without proof. With a log, it becomes a verifiable fact. That is why laws and standards explicitly require such records in many areas, such as accounting, hospitals, and the processing of personal data.

The second reason is troubleshooting. When a service goes down at 3 a.m., the first question is always: what changed beforehand? A log provides the answer in minutes instead of days. Without a record, developers would have to guess which of the dozens of changes made the day before was to blame.

With AI systems, there is a third reason. A model decides on credit applications or filters job applications, and those affected have a right to find out how that decision came about. In that case, what gets logged is not just the decision itself, but also which model version made it and what data it was trained on. The EU’s AI Act requires exactly this kind of record-keeping for high-risk systems.

Appending instead of overwriting

The basic technical principle is called append-only, meaning only adding, never overwriting. New entries are added at the bottom, existing ones are never changed or deleted. A log therefore only ever grows, it never shrinks. Anyone wanting to correct a wrong booking adds an offsetting entry instead of deleting the old one.

To ensure no one secretly tampers with entries afterward, systems additionally secure them. A common method calculates a kind of fingerprint from each entry, a short checksum. This number feeds into the checksum of the next entry. If someone changes an old entry, all subsequent checksums no longer match, and the manipulation becomes apparent. The same principle underlies blockchain, which at its core is nothing more than a log without a central owner.

A common misconception is that a log is the same as a backup. A backup is a copy of the state at a given point in time. A log, by contrast, describes the path from one state to the next. From an old backup plus the log, any later state can be restored, but not the other way around.

From Wikipedia to the data center

You encounter this principle constantly in everyday life. Every Wikipedia article has a version history tab with every edit since the first day. A chat history shows when a message was edited. And a bank statement is essentially a log of all movements on the account.

In software development, the most important tool for this is Git. It stores every change to program code as its own entry, complete with author and reasoning. Large companies also run systems that collect and make searchable millions of log lines per second. Because such volumes of data are expensive, there is often disagreement about how long everything should be kept.

In business news, logs usually come up when they are missing or have gaps. After data breaches, the crucial question is regularly whether it was even recorded which data was leaked. If the audit trail is missing, a company cannot even put a number on the damage.