# The Log-File Template (Chapter 13)

**Use when:** an automated run touches a system, or a colleague's Monday depends on the output. Every run keeps an audit trail, and this is the shape: a plain file, one line per entry, timestamp, system, action, result.

It is boring, and boring is the feature. The day someone asks "who entered Tuesday's numbers," the log answers, and the log makes the difference between "an agent did it" and "here is exactly what happened, in order."

## The CSV shape, one line per entry

```
timestamp,system,action,result
```

Filled rows, synthetic:

```
2026-08-04T07:12:31,erp,entered total for record R-001,ok
2026-08-04T07:13:04,scheduling,split total by line for record R-001,ok
2026-08-04T07:14:22,time-tracking,entered week fields for record R-001,ok
2026-08-04T07:15:47,compliance-tracker,verify pass record R-001,4 of 5 expected, stopped, map updated, re-ran
2026-08-04T07:17:02,compliance-tracker,verify pass record R-001,5 of 5 expected, ok
```

One line per entry, written as the action happens, never batched from memory at the end of the day.

## Rules that keep the log honest

- Every action has a row: what was clicked, typed, or submitted, in what system, at what time, with what result.
- Failure rows are log rows too: the off-by-one count, the skipped field, the stopped run. The log that only ever says "ok" is the log nobody reads.
- The log is data, so it follows the same rules as any other file: store it where only the intended readers can access it, and never include credentials.
- Review the log and the verify summary in the morning; handle the exceptions; let the run do the typing.

## When the obligations grow

The moment your systems feed someone else's Monday, the log stops being a good habit and becomes an audit obligation: verification a stranger could run, and evidence that the work is right. Finance asks for it exactly once, and that once pays for the habit.