# The Changelog Format (Chapter 14)

**Use when:** a shared tracker or tool has users. The changelog habit starts with the share: one line per change, written in place, and the maintenance load stays about an hour a month.

The changelog is how you can name the last change and why, and it is the maintenance contract made visible. Someone asks for a field, someone flags a bug: you change it in place and write one line. The shared version is the only version.

## One line per change

```
date | what changed | why | who
```

Filled rows, synthetic (Sam's tracker, month one):

```
2026-08-12 | Added a notes field to intake rows | Facilities asked to track handoff details | Sam
2026-08-19 | Fixed the date filter off-by-one | PMO flagged wrong week in summary | Sam
2026-09-02 | Declined a requested export button | Would push maintenance past an hour a month | Sam
```

## The three rules

- One line per change: what changed, why, when. Three fields, no essays. The changelog that needs editing is the changelog nobody reads.
- Change it in place. The shared version is the only version, so the changelog and the file can never disagree about what is current.
- Watch the hour. The day maintenance becomes a day is the day you decline a feature, which is part of the job. Saying no to a request is a changelog line too, with the reason.

## Verify

You can name the last change and why, without opening the file. The maintenance load for the month fits in an hour, and the changelog page says so.