How to Keep a Running Change Log Across All Revision Versions of a Film Edit

A film edit that goes through twenty versions without a running change log is a guessing game by the time you reach version fifteen. You have a producer asking why a scene that was removed in version nine is suddenly back in version fourteen. You have an editor who cannot remember whether a specific note was from the director or the distributor. You have a deliverable that needs to be cut back to a picture lock that nobody can reliably reconstruct because the notes from that period are scattered across three email chains and a folder of PDFs.

Keeping a running change log across all revision versions of a film edit is simple in principle and consistently neglected in practice. Here is how to build the habit and the system.

What a Change Log Is Not

Before covering what to include, let me be clear about what a change log is not.

It is not a shot list. It does not list every clip in the cut.

It is not a note document. It does not contain every note that was given. Notes are inputs. The change log records the changes that were made in response to notes.

It is not a version history folder full of exports. Those are the artifacts. The change log is the record of why each version is different from the previous one.

The change log is a human-readable record that answers the question: "What changed between version X and version Y, and why?"

The Minimum Viable Change Log Entry

For each new version of the cut, the change log entry needs four things:

Version number and date. Formatted consistently. v07, 2024-03-12. Not "March 12" and not "v7". Consistent formatting matters because you will sort and search this document.

Source of changes. Who asked for these changes? Director pass, producer notes, client round two, broadcast note, distributor request. Not a full name necessarily, but the authority and occasion.

List of changes. Specific enough to locate in the cut. Not "changed the opening" but "reordered opening montage, moved B-roll of city at dawn from sequence 2 to sequence 1 start." Not "tightened the third act" but "removed the scene at the gas station between characters A and B, total time removed approximately 2 minutes 20 seconds."

Notes on anything deferred. If a note came in and was not addressed in this version (deferred to the next pass, or rejected), that belongs in the log too. "Director requested the kitchen scene be shortened; held over to v08 pending producer review."

Here is a minimal but useful log format:

v07 | 2024-03-12 | Director pass (session notes from 2024-03-10)
- Removed gas station scene between A and B (approx 2:20 removed)
- Moved city dawn B-roll to open of act one
- Tightened dialogue in hospital lobby, removed three beats of silence after the argument
- Added 8 frames of black before title card per director preference
Deferred: director wants to revisit the score temp in act two; holding for v08

That entry takes five minutes to write and saves an hour of confusion later.

Where the Change Log Lives

The change log should live in one place and one place only. It should not be replicated across email, Slack, a production management tool, and a notes folder. Pick one location, stick to it.

My recommendation: a plain text or markdown document in the production's shared drive, named something like NGT_CHANGE_LOG.md. It travels with the project. It is not inside the NLE project file, because that file is not always accessible to everyone who needs to reference the log. It is in the shared drive where the coordinator, the producer, and the editor all have access.

If your team uses a production management tool, a dedicated section for the change log works there too. The key is that it is the single source and everyone knows it.

Connecting the Change Log to the Review Platform

The change log documents changes. The review platform documents what was reviewed and approved. These two systems are complementary but different, and the best workflows connect them.

In PlayPause, when you upload a new version of the cut, you can add a version description. I use this to add a one-line summary of the main change: "v07: director notes from March 10th applied; gas station scene removed; act one opening revised." This gives reviewers immediate context when they open the new version.

Then in the change log, you reference the review session. "v07 notes reviewed and approved by director via PlayPause review session, 2024-03-14." Now the change log and the review platform cross-reference each other.

Practical Discipline: Writing the Entry at Export Time

The biggest obstacle to maintaining a change log is timing. If you try to reconstruct the log after the fact, you will miss things and get details wrong. The log entry needs to be written at the time the version is exported, not days later.

Build this into your export workflow. Before the editor exports a new version:

1. Write the change log entry for this version
2. Confirm with the editor that the entry is accurate
3. Export the version with the correct naming convention
4. Upload to PlayPause with the version description that summarizes the entry

This takes five extra minutes. It prevents hours of confusion at the next review session.

Using the Change Log When Something Goes Wrong

The change log is most valuable when something breaks. A distributor calls and says a version they approved three months ago had a different ending than the theatrical cut. You open the change log and find the version, the date, the note source, and exactly what changed between the version they approved and the current cut. Instantly.

A director comes back after picture lock and says a scene was in a version they liked but they are not sure which one. You search the change log for the scene name and find the version it first appeared in and the version it was removed in, with the note source for each change.

With no change log, those conversations require archaeology. You are opening old exports, hunting through email chains, and asking the editor to try to remember things from three months ago. With a change log, the answer is a thirty-second search.

• Start the change log before the first export
• Write each entry at export time, not after
• Include note source, specific changes, and deferred items
• Reference the change log entry in the review platform version description
• Archive the completed log with the final delivery package

For more on the systems that connect to this one, the guide on cut version naming conventions for a post production team covers the file naming side of version management. And the picture lock documentation guide on how editors prove a cut was approved covers the approval record side.

A running change log is cheap to maintain and expensive to not have. The discipline of five minutes per version saves hours of confusion on every project where something goes sideways, and something always does. Start a PlayPause workspace for free and build the change log reference into your version upload description from day one.