Cut Version Naming Conventions That Actually Work Across a Post Production Team

Version confusion is one of the most common and most preventable problems in post production. Someone renders a file, names it something reasonable, and by the time it has been emailed around a few times and renamed by three different people, nobody can tell which one is current. Editors working off the wrong cut. Sound designers syncing to an outdated export. Clients approving something that got superseded two days ago.

Cut version naming conventions for a post production team sound like a small, boring problem. They are actually a significant source of wasted time on mid-size and larger productions, and the solution is simpler than most teams make it.

Why Teams Default to Bad Naming Conventions

The reason file naming goes wrong is that each person on a team has their own shorthand that makes sense to them. The editor names files for their own navigation. The post coordinator renames them for their tracker. The client saves a download with whatever name their browser assigns. When everyone is using different conventions, the file names mean nothing.

Here are the failure modes I see most often:

• Using "final" in a filename (always wrong, because nothing named "final" ever actually is)
• Using dates without a version number (two exports on the same day cause immediate confusion)
• Generic names like "cut_v2" without a project code (useless across more than one project)
• Different team members using different date formats (20240115 vs 01-15-24 vs Jan15)
• No indication of what changed between versions

The fix is a shared convention that every person on the team uses from day one.

The Naming Convention Format That Works

After running a lot of productions through this, here is the structure I recommend:

[PROJECT CODE]_[DELIVERABLE]_v[VERSION NUMBER]_[STATUS FLAG]_[DATE]

Breaking that down:

Project code: A short abbreviation of the project name. Two to four characters. Consistent across all files in the production. If the film is called Northgate, use NGT.

Deliverable: What the file is. THEATRICAL, BROADCAST, TRAILER, EPK, TEASER, SPOTS. This distinguishes between multiple deliverables on the same project.

Version number: Always padded to two digits. v01, v02, up to v99 if needed. Never "v1" or "V2" or "version_three."

Status flag: Optional but useful. DirApproved, ProducerApproved, PictureLock, ForSound, ForColor, ForVFX, ForClient, ForBroadcast. One word, no spaces.

Date: YYYYMMDD. This format sorts chronologically in any file system. 20240312, not March 12 or 12/03/24.

A real example: NGT_THEATRICAL_v07_DirApproved_20240312.mp4

Anyone on the team who picks up that file knows it is version 7 of the theatrical cut of Northgate, the director approved it, and it was exported on March 12th, 2024. No ambiguity.

Handling Multiple Editors on One Project

When more than one editor is working on the same project (assistant editors, additional editors, VFX teams handing back shots), you need an additional layer to track who produced a file.

Add an optional initiator tag after the deliverable name:

NGT_THEATRICAL_[EDITOR INITIALS]_v07_DirApproved_20240312.mp4

This matters when you have an assistant editor producing an export and the main editor doing a separate assembly. It also matters when external vendors send back files with their own naming. The initiator tag lets you track where a version originated.

Applying Conventions When the Review Happens Outside the Edit System

File naming conventions matter even more when cuts leave the edit suite for client or stakeholder review. When a director reviews a cut in PlayPause, they see the filename you uploaded. If that filename is clean and follows your convention, they know immediately what they are looking at. If it is "final_cut_REAL_v2_USE_THIS.mp4," they already have questions before they have watched a frame.

In the version description field when uploading, you can note what changed between versions. I recommend using this to note what changed between versions. Not a full change log, just one line: "V07: director's notes from March 10th applied, kitchen scene reordered, title card revised." This gives reviewers context without them needing to watch the whole cut from scratch.

This connects directly to the idea of keeping a running change log across revision versions of a film edit. The version description in your review platform and the change log in your production files should agree.

Folder Structure That Supports Good Naming

Naming conventions only work if the folder structure supports them. Files with perfect names get lost in poorly organized folder hierarchies.

My recommended top-level structure for a mid-size production:

/NGT/
 /Exports/
 /Theatrical/
 /Broadcast/
 /Trailer/
 /For_Review/
 /Client/
 /Director/
 /Sound/
 /Approved/
 /PictureLock/
 /FinalDelivery/

The Approved folder is important. Once a version has been formally signed off, move it to the appropriate subfolder in Approved. Nothing in the Approved folder should be a live working file. It is the archive of what was confirmed.

Enforcing the Convention Across the Team

• Document the naming convention in the production bible before any files are created
• Share it with every team member and every vendor on day one
• Assign the post coordinator to audit file names weekly
• Never accept an uploaded or emailed file with a non-conforming name; rename it immediately
• Use version descriptions in your review platform to supplement the filename record

The hardest part of any naming convention is enforcement. The convention does not enforce itself. Someone on the team will call a file "final_FINAL_submit_this.mp4" because they are rushed. Your job as the coordinator or post supervisor is to catch it and rename it before it spreads.

For assistant editors managing revision markers and version exports, the guide on organizing revision markers before a director review covers the operational side of this in more detail.

Good naming conventions are a quality gate. They prevent the kind of version confusion that leads to approving the wrong cut, delivering an outdated file, or having a director who approved version 5 discover the delivery was version 7 with changes they never saw. Set the convention at the start, enforce it consistently, and your whole team will spend less time hunting for the right file. Start a free workspace on PlayPause and make the version label on every upload part of your naming system from day one.