Keep an Editorial Decision Log That Someone Will Actually Read

A new account director opens a release after ten rounds of review. The headline is oddly cautious, a customer example has gone and the quote is shorter than anyone remembers agreeing. There are dozens of comments and no answer to the only question that matters: were those changes deliberate?

Keep a decision log, and keep it small. Log only the choices that change meaning, evidence, authority or later work, each in six fields with a named owner, and leave style edits in the document history. A log that tries to record every conversation stops being read by the second week.

Software teams have used the same idea for years. The UK Government Digital Service↗ tells its teams to record architecture decisions to preserve the context of their choices, because the reasoning is hard to keep track of as new people join and early contributors leave¹. Its guidance adds that kept reasoning shows whether a choice was made for expediency and can change with little impact, or rested on outside reasons that still apply¹. A PR account that changes hands mid-project has the same problem, and the same fix.

Four kinds of decision belong in the log: scope and factual wording, disclosure and use, voice and attribution, and approval and release.

Six: date and time, draft version or link, decision, reason or evidence, owner and status.

Add a short consequence when it affects the next action. Keep the wording factual. “Revised availability from nationwide to two named locations. Launch plan dated [date] confirms those locations only. Product owner: [name]. Client accepted v4 with this scope. Closed.”

This fictional entry lets a later editor understand the choice without reading a meeting transcript. It also exposes what is absent. If the source did not establish public use, or the client accepted copy but release authority remains open, the status should say so. A log works when it keeps uncertainty visible rather than converting it into a tidy but misleading conclusion.

The shape is borrowed from software. Michael Nygard’s architecture decision records↗ give each decision its context, the decision itself, a status such as proposed, accepted or superseded, and its consequences, all short enough to read in a minute².

At the start of each review and before the next version is sent, so new decisions are in the log before anyone edits again.

Link entries to comments or source passages where that helps, but do not make reviewers chase a trail of references to understand the main point. Use a short “open decisions” section at the top for items that block a claim or release. When reviewers disagree, log the outcome only once the conflict is settled, after sorting conflicting draft feedback into one decision.

During handoff, ask the receiving person to read the log before editing, whether the move is permanent or a short handover while the account lead is away. Their first question should be “what remains unresolved?” rather than “what happened here?” At final release, use the log to confirm the current version, required approvals and any promises to update. After release, retain the decisions with the final copy and its evidence.

Two habits kill them: logging every conversation, which buries the decisions, and writing entries with no owner, which leaves the next person unable to trust them.

First, do not log every conversation. A long chronological diary hides the decisions that matter. Summarize the result and link to detail if someone needs it. Second, do not write entries that avoid ownership: “team agreed” leaves the next person unable to confirm whether the team had authority. Name the responsible role or person, even when several people contributed. The UK government’s decision record framework↗ was written partly to make sure decisions are made at the appropriate level and with the right stakeholders³. An editorial log can ask the same of every entry: was the named owner entitled to make this decision?

There is a tradeoff. A very detailed record can slow a small, low-risk edit. A very sparse record makes complex work impossible to hand over. Calibrate the log to materiality. If an edit changes a public claim, attribution, disclosure boundary, promise or approval status, take the minute to write it down. If it is purely a style correction with no downstream effect, leave it in the document history.

Start with one live draft and a short table of open and closed decisions, not a retrospective sweep of old files.

Choose one active deliverable and keep a short table of open and closed decisions. Add entries as the team works, then ask at handoff whether the log answered the receiving editor’s first questions, and adjust the fields based on that answer.

Part of the log can keep itself. QuoteIt records each approval against the version it covered, so the who-approved-what column is already there; the reasons behind editorial choices still need a person to write them down.

A useful decision log is quiet infrastructure. It prevents memory from becoming the only record of why a sentence exists, why another was removed, and what still needs authority. Keep it brief enough to open, concrete enough to trust, and close enough to the draft that it is used before the next avoidable version cycle begins.