A folder containing “final,” “final-new” and “final-really” is asking a team to reconstruct its history. The solution is not a longer filename for every export. Agree on a few distinctions that matter, then use them consistently.
Start by separating the working project, review exports and approved delivery files. These have different jobs. The name should help someone recognise which job a file serves before opening it, without pretending that a filename alone proves approval.
Choose a readable pattern
Use a short project identifier and a version number that advances in a predictable way. Add a date where it helps the team distinguish work sessions. Agree on the date order rather than mixing several regional formats.
A pattern such as “Harbour_cut_v04_2025-02-18_review” is an illustration, not a required convention. Your project may need a scene name or language label instead. Include only information that people will actually use to choose a file.
Avoid private abbreviations that make sense to one editor. Write a small key in the project notes if shortened labels are necessary. The team should be able to distinguish a review export from an approved delivery without remembering a conversation from three weeks earlier.
Define what changes the number
Decide whether each review export receives a new version and how working saves are handled. Follow the editing software’s own guidance for saving and backups; a naming agreement does not replace those functions.
Use a new review number when the content changes in a way reviewers need to distinguish. If a technical re-export leaves the cut unchanged, label that fact clearly in the handover note. The important point is that two different files should not circulate under an indistinguishable description.
Do not overwrite the copy currently being reviewed without telling the team. Notes referring to a replaced version can become impossible to interpret. Keep the relevant reference available according to your agreed retention and access arrangements.
Put approval in the record
A file named “approved” is not proof that the responsible person approved it. Record who confirmed the version, when they did so and what the approval covered. A picture edit approved for sound work may still be unsuitable for public delivery.
Keep a short current-status note where the team can find it. It might say which project version is active, which review export corresponds to it and which earlier versions should no longer receive notes. Update this when responsibility passes to another person.
Before sending a file, open the intended export and check that its content matches the name and message. A neat naming scheme cannot rescue an attachment selected from the wrong folder.
Make the handover small enough to read
Send one clear sentence identifying the file, followed by the action you need. “Please review v04 for story clarity by Thursday” gives the recipient a task. A long list of every change may be useful separately, but it should not hide which version they should open.
When the project closes, keep the final status record with the retained materials. Remove ambiguity before memories fade. The goal is modest: someone returning to the film should be able to identify the relevant version without asking which “final” you meant.