An audit log needs old values

The question a log gets asked

Logs are never read casually. They get opened during a disagreement, and the disagreement is always specific.

This leave request was approved and now it is not. This timesheet says submitted and the person says they never sent it. This device shows as returned and it is on someone's desk.

Each of those needs a field, a previous value, a new value, a person and a time. An entry that says record updated sends the reader back to asking people what they remember.

What we record

Each entry names the entity, the action and the change, with the previous and new value side by side. Status moved from draft to submitted reads as a sentence, not as a diff someone has to decode.

The log runs to thousands of entries in daily use and is paginated accordingly. Quick filters cover today and this week, and the main entity types: users, projects, checklists.

Creates, updates and deletes are filterable separately, because those are three different investigations. A deletion is usually the one being looked for.

Beyond that there is filtering by user, by entity, by action and by date range, which is what turns a large log into a usable one.

• Entity, action, and the field that changed.
• Previous value and new value, together.
• Who made the change, and when.
• Creates, updates and deletes filtered apart.
• Filters by user, entity, action and date range.

Reading the log well

Start from the record, not the person. Filter by entity and date range, and every change to one timesheet or one project reads top to bottom, in order.

Then look at who. A run of edits by one account in one afternoon is usually a clean-up. A single edit to an old record is usually the one worth asking about.

The log records changes, not intent. Knowing who changed a status tells you who to ask, and the conversation does the rest.

Why this changes behaviour

A readable log shortens arguments. Five minutes of checking replaces an afternoon of asking, and nobody has to rely on what they remember.

It also changes how people treat the system. When a change is visibly attributed, quiet edits stop, and the ones that do happen get explained at the time.

That effect is worth more than the forensic use. Most entries will never be read. The ones that are, are read on a bad day.

The entries that turn out to matter

A few kinds of change earn their place in the log far more often than the rest.

Status transitions. Draft to submitted, pending to approved, active to retired. Almost every dispute is really a disagreement about when one of these happened.

Assignment changes. Who a device went to, who a running process was handed to, who a meeting was moved under. These get changed casually and remembered wrongly.

Deletions, always. A missing record is the hardest thing to investigate without a log, because there is nothing left to look at.

Configuration changes deserve the same treatment. A threshold quietly edited explains a month of reports that stopped making sense.

Using it without becoming a detective

A log invites a habit that is worth resisting: checking up on people because you can.

The useful posture is reactive. Open it when something does not add up, answer the specific question, close it. Browsing it for patterns about individuals is a different activity and a corrosive one.

There is a decent test. If you would not be comfortable telling the person you looked, you are not investigating a record any more.

Used that way, a log mostly ends arguments rather than starting them, which is the whole reason to keep one.

Reading a log without jumping to a story

A log is a sequence of facts, and people are very good at turning a sequence into a motive.

Somebody changed a status at eleven at night. That could be diligence, a different time zone, or a batch job running under their account. The row says none of it.

Somebody edited the same record four times in an hour. Usually that is a form fighting back, not somebody being evasive.

So the honest use is narrow: establish what changed and when, then ask the person. The log settles the sequence. It does not settle why.

Teams that skip the asking step get a reputation for the log rather than for the process, and then everyone starts working around both.