The decision log that ends repeat feedback
A one-page log of closed decisions, including rejected options, plus the scripts for citing it when a note returns three rounds later from someone new.
The note that damages a project is rarely a hard note. It is a note you already answered. Round four, a stakeholder who was not on the round-one call, and the question is why the logo is not bigger — when the logo is that size precisely because the brand team asked for it smaller six weeks ago. You know that. Your evidence is a Slack message nobody is going to scroll to, so you either re-argue it for free or you make the change and quietly break something that was decided on purpose.
A decision log fixes this for about ten minutes of work per project. It is the least glamorous artifact in a production process and the one with the best ratio of value to effort, because the thing it prevents — re-litigating settled questions — is unpriced and unbounded.
What it is, and three things it is not
It is a list of closed questions, each with a decision, a date, an owner and a link to what they were looking at. That is all.
It is not a changelog of files. Filenames and versions are a different discipline and a different document; asset naming and version discipline and version control for brand creative assets cover that half properly. A decision log records why v4 differs from v3, not that it does.
It is not meeting minutes. Minutes record what was discussed, which is mostly noise. The log records only what closed.
It is not a defence file. The moment it starts reading like one, it stops working, for reasons covered further down.
The format
One table, one page, one row per decision.
| ID | Date | Question | Decision | Decided by | Evidence | Status |
|---|---|---|---|---|---|---|
| D-01 | 4 Aug | Which direction? | A, "Quiet proof" — product-led, no VO | Marketing Director | Concept board link | Locked |
| D-02 | 6 Aug | Presenter or product only? | Product only. Presenter version rejected: "feels like an infomercial" | Marketing Director | Key frame 03 | Locked |
| D-03 | 6 Aug | Logo treatment | Small, bottom-left, final 3s only | Brand team, via Marketing Director | Key frame 07 | Locked |
| D-04 | 11 Aug | Music | Track D approved. Track B rejected as too upbeat | Marketing Director | Preview v3 | Locked |
| D-05 | 12 Aug | Caption style | Brand preset, no emoji | Marketing Director | Preview v4 | Locked |
| D-06 | — | End card CTA wording | — | Awaiting legal | — | Open |
Five rules make the difference between a log that works and a document nobody opens.
Record the rejected option, not just the chosen one. This is the single highest-value habit here. Nobody comes back asking for the thing you built; they come back asking for the thing you did not. D-02 is only useful because "presenter version rejected" is in it.
Quote the client's own words. "Feels like an infomercial" is far more persuasive to a colleague of theirs than your paraphrase, and it removes any suggestion that you are characterising their reasoning.
Write the row the same day. A log reconstructed at the end of the project is a reconstruction, and it reads like one.
Link the artifact they were actually looking at. A decision without the thing it was made about is a claim. Saving the approved frame or cut into a named project gives the evidence column somewhere permanent to point — saving generations to a project does not spend generation credits and skips anything already saved, so the trail costs you a line of typing rather than a rebuild.
Keep it to a page. If it runs long, you are logging notes rather than decisions. Timing tweaks and caption edits are not decisions; direction, casting, brand treatment, claims and format are.
Where it lives
In the same place as the brief, the previews and the approvals. The reason is mechanical rather than philosophical: context that lives apart from review, feedback and versioning has to be rebuilt by hand every time it moves, and anything rebuilt by hand eventually is not. A decision log stored somewhere other than where the work is reviewed will be out of date within two weeks.
The practical minimum: one document, linked from the top of every delivery message, with the last five rows pasted into the message body. Almost nobody clicks the link. Everyone reads the five lines. The team handoff workflow covers what else travels with a deliverable when more than one person touches it, and content approval workflows that don't stall covers the queue problem that a log alone will not solve.
Update it at the gates
Do not maintain it continuously; that is how it becomes a chore and then a fiction. Each review gate produces rows, and the gates are the only moments that produce rows: concept locks direction and format, the key-frame gate locks casting, set and brand treatment, the motion gate locks performance and camera, the export gate locks timing, captions and spec.
Send the new rows with the artifact, phrased as what is now closed rather than as a record: "Locking these three as approved — direction A, product-only, logo on the final beat. Shout if any of those look wrong before I build on them." That sentence is doing the log's real job, which is not to win an argument later but to give someone a last, cheap chance to object now.
How to cite it without sounding combative
The tone rule that matters most: the log is a memory aid, not evidence. Every phrasing below follows from that.
A new stakeholder asks to reverse something. Do not lead with the log.
"Happy to look at that. Flagging one thing so you have the context: we locked product-only at the key-frame stage on 6 August, because the presenter version read as an infomercial to the brand team. If the thinking's moved on, that's completely fine — it's a change of direction rather than a tweak, so I'd quote it before starting. Want me to put a number on it?"
Three moves in that: agreement first, the fact in neutral language, and a route forward with a price. A log entry that closes a door and offers no door is just a refusal with a citation.
The same person changes their own mind on something small. Do not cite the log at all. Make the change. Citing a written record over a caption tweak is how a log turns into a defence file, and once a client perceives that, every subsequent citation reads as adversarial regardless of how it is worded. Reserve it for reversals that cost real work.
Two stakeholders contradict each other. Put the conflict between them rather than between you and them.
"I've got two directions on the logo — the brand team's note from 6 August has it small and on the final beat, and today's note has it throughout. Can you two land on one and I'll update the log either way?"
You are not defending a decision. You are asking for one, which is what they are for.
Some things should stop being feedback entirely
A subset of what ends up in the log is not project-specific at all: brand caption style, no emoji in captions, a competitor never named, a standing frame-rate requirement. Those belong upstream, where they apply without anyone remembering to apply them. You can teach the agent a lasting preference once and have it hold across sessions rather than repeating it in every brief — long-term memory preferences covers what that persistence does and does not cover.
The test for whether something belongs in the agent's memory rather than the log: would this be true on the next project for this client too? If yes, it is a standing preference. If it is only true of this piece, it is a log row.
FAQ
Should the client see the log?
Yes, from day one, and it should be dull. A log the client has been reading all along is a shared reference; a log produced for the first time during a disagreement is an ambush, and it will be read as one no matter how it is written.
What if a decision was made verbally on a call?
Write the row and send it the same day: "Capturing what we agreed on the call — product only, no presenter. Correct me if I've got that wrong." Confirmed-unless-corrected is a normal way to close a verbal decision and takes one line.
Does this replace a revision policy?
No. The policy sets the commercial terms; the log records what happened under them. They work together — most classification arguments about whether something is a refinement or a change of direction dissolve when there is a dated row showing what was locked and by whom. Client reporting for content freelancers is where the log's summary belongs in the regular client-facing document.
How long should I keep it after the project ends?
For as long as the client might come back for a follow-up, which in practice means indefinitely — it is a page of text. The second project for the same client is where an old log pays out fastest, because the standing preferences are already written down and the brief starts half-finished.