Changelogs and memory.

Every change, with its reason, with its author

The entry format never varies: what changed, why, who. The why is the payload. A year later, nobody argues with a decision that carries a date, an owner and a reason. They either accept it or supersede it with a new entry. The same argument stops being had three times, which in a four-founder company is worth more than most features.

The entries that matter most are the unflattering ones

A real example, public on the GreenRoom brain’s changelog: a review round flagged the layout spacing as a taste problem. It was not a taste problem. The margins were a CSS bug. The entry records that under the heading root-caused the margins instead of adjusting them, because the lesson is the distinction itself: a layout that looks wrong is usually broken rather than badly judged, and nudging values hides the fault instead of removing it.

When generated output was wrong and got caught, the log says so. A system that hides its own corrections teaches the next person nothing, and a log that only records victories is marketing, not memory.

A change is not done until the system agrees with it

Editing the file is the start, not the finish. The change is finished when the log records it, the generated twins are rebuilt so no copy of the rules drifts from another, and a stale-reference sweep comes back clean. A brain that disagrees with itself, a routing table pointing at a file that moved, a constitution describing a capability that was removed, teaches people not to trust it one small contradiction at a time.

Decisions are memory too

Beside the changelog sits a decisions log: what was decided, when, by whom, including the decisions the AI must never reopen. It is the file that stops a helpful assistant from relitigating a settled question at 11pm, and it is where a client’s we already answered that becomes enforceable.