Keep an Editorial Decision Log That Someone Will Actually Read

A new account director opens a release that has been through ten rounds of review. The headline is oddly cautious, a customer example disappeared, and the quote is shorter than expected. There are dozens of comments, but no one can say whether those changes were deliberate, temporary or simply lost during a rewrite. The director starts asking the same questions the team answered last week.

An editorial decision log records only choices affecting meaning, evidence, authority or subsequent work. A useful log reduces repeated debate because it keeps the decision with its reason. Vague notes and routine comments belong in the document history rather than a second sprawling record.

A practical entry has six parts: 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.

Open the log at the start of a review and place new decisions there before the next version is sent. Link entries to comments or source passages where that helps, but do not require reviewers to navigate a maze of references to understand the main point. Use a short “open decisions” section at the top for items that block a claim or release.

During handoff, ask the receiving person to read the log before editing. 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.

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.

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.

Do not launch a retrospective logging project across every old file. Choose one active deliverable and create a short table with open and closed decisions. Add entries as the team works, then ask at handoff whether the log answered the receiving editor’s first questions. Adjust the fields based on that answer.

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.