Create a File-Naming System That Survives Collaboration

AI-generated conceptual illustration; not a product screenshot, measured result, or factual diagram.

A filename is a tiny handoff. It should tell the next person what they are opening, which deliverable it belongs to, and whether another version has replaced it. It cannot carry the whole history of a project, and asking it to do that usually produces names nobody follows.

Consider a fictional campaign for a neighborhood repair studio called Mend. A designer makes posters, an editor cuts an interview, and a producer sends approved exports to a venue. They work on different computers. The useful question is not whether their folder looks tidy. It is whether the producer can find the approved portrait video without opening six files or asking the editor which “final” is final.

This workflow creates a short naming convention, a source-media exception, and a release record. The names and campaign are invented examples, not a report of a tested production system.

Start with the questions people actually ask

Before choosing separators, collect five common retrieval questions. For Mend, they are: Which campaign is this? Is it the poster or the interview? Which language and shape does it use? Which revision is it? Was this exact export approved for delivery? Those questions suggest a small set of fields rather than a universal naming taxonomy.

Use the first four questions in the filename. Put approval evidence in a release manifest. Approval can change without the underlying bytes changing, and the person who approves the piece may not control the filesystem. Encoding approval only in a word such as “approved” creates a second, easily outdated status system.

A workable Mend export name is mend-interview-en-portrait-v003.mp4. It identifies campaign, asset, language, format variant, and revision. The manifest identifies that exact file as approved, names the destination, and points to the approval record. A source project might instead be mend-interview-edit-v003.prproj. Project and export versions need not be equal; the manifest records which project produced which export.

Define a small vocabulary

Choose words once and write them down. If portrait, vertical, and story all mean the same deliverable, pick one term. Otherwise people will search for different labels and mistakenly conclude something is missing. When two variants genuinely differ, describe the distinction explicitly: portrait-captioned and portrait-clean are different outputs, even when their pictures match.

Give the convention a compact grammar: campaign-asset-language-variant-version.extension. For this example, campaign and asset are required, language appears only where relevant, variant identifies the delivery difference, and version is always three digits preceded by v. Do not make collaborators infer whether a missing field means unknown, irrelevant, or accidentally omitted. Show an example for each allowed asset type.

Keep a vocabulary list beside the project: interview, poster, lockup; en and es; portrait, landscape, print; v001 onward. These are local project choices, not universal standards. If the campaign grows into a large localization program, replace improvised language abbreviations with an agreed locale scheme and update the examples before the first translated delivery.

Make the characters boring

A conservative shared convention uses lowercase letters, digits, and hyphens, with the normal file extension preserved. This is a practical team choice, not a claim that all other characters are invalid. Its advantage is predictability when a file moves through download links, archive tools, and different operating systems.

Windows has reserved characters and device names, and Microsoft advises against assuming filenames are case-sensitive. Avoid creating two deliverables distinguished only by capitalization. Also avoid trailing spaces or periods. These constraints are documented in Microsoft’s file-naming reference.

Keep the full path short enough for the applications and destinations you actually use. There is no single safe maximum that covers every service. A moderate filename inside a deeply nested campaign folder can still become awkward. Test a representative path in the delivery tool instead of relying on the filename’s length alone.

Protect camera originals and their folder structure

The naming policy should explicitly exempt camera originals, production audio, and any media package whose software expects a particular structure. Do not rename these files merely to make them visually consistent with exports. Add descriptive context in their enclosing ingest folder and in the editing application’s metadata where the workflow allows it.

For Mend, a folder named 2026-10-12-camera-a-card-01 can contain the card’s original structure. A second card gets a separate folder even if both contain a clip named C0001. The folder identifies provenance; the unchanged original name preserves the relationship to the recording. Keep sidecar files with the media they belong to.

Renaming or moving already linked media can require relinking. Adobe’s offline media guidance describes locating missing source files. Treat that as a recovery mechanism, not permission to reorganize a live edit casually. Test a copied project before any planned migration, and retain a mapping from old paths to new paths.

Let folders do a different job from filenames

Mend can use a shallow project structure: sources, working, review, delivery, and records. Sources contain preserved inputs. Working contains editable projects and their dependencies. Review contains exports sent for feedback. Delivery contains the selected release copies. Records contains the naming guide, approvals, rights references, and release manifest.

Do not repeat every folder name in every file. A working poster does not need mend-working-design-poster-project-artwork-v003.ai. The useful filename is mend-poster-v003.ai, because its extension and folder already supply some context. Exports need more context because they are more likely to leave their folder and arrive alone in an email or download.

Avoid a folder called old that becomes the only evidence of version history. A file can be superseded without becoming meaningless. Preserve earlier review versions where retention permits, and make the current release discoverable through the manifest. Folder movement alone is a weak explanation of why a file changed.

Separate revision, branch, and export settings

Increment the revision when the creative content changes. In this example, v002 changes the interview’s opening; v003 corrects a caption. A different encoding of the same approved edit is a separate rendition, not necessarily a new creative revision. Distinguish those renditions with a meaningful variant or with manifest fields.

Parallel experiments need names too. If the designer explores a typographic and photographic poster, use concept-a and concept-b while they remain alternatives. Do not call them v004 and v005 if that implies one supersedes the other. Once a concept is selected, record that decision and return to one revision sequence for the chosen deliverable.

Have one person reserve or assign the next shared version when simultaneous work could collide. For a tiny team, a line in the manifest may suffice. For a larger team, use the collaboration features of the actual authoring system. A filename cannot merge two people’s changes or prevent a sync conflict.

Work through the handoff

Suppose the editor sends mend-interview-en-portrait-v003.mp4 for review. The producer records the file, its location, the review link, and the requested destination. Feedback asks for a spelling correction, so the editor creates v004. The producer does not rename v003 to v004 or overwrite it in place, because the earlier comments refer to the earlier picture.

When v004 is approved, the manifest records the approval date, approver, scope, and exact file. The delivery copy retains its informative name. If the venue requires a fixed filename such as screen.mp4, the producer makes a delivery copy with that name and records the mapping. The original campaign export remains traceable.

A useful manifest row reads in plain language: delivery screen.mp4 comes from mend-interview-en-portrait-v004.mp4, approved for the venue display, exported from project revision v006. The row can also include file size or a checksum if the team has a reliable verification process. Do not type a fabricated checksum or assume matching filenames prove matching bytes.

A release mapping without a misleading filename

This fictional row describes how the handoff would be recorded after approval. No real file, checksum, approver or delivery is asserted.

The fixed destination name does not change the rendition. A landscape request would require a separately composed/exported file and its own applicable approval; renaming a portrait file cannot supply it.

Test the convention before migrating anything

Create a small rehearsal with copies, not production originals. Include two language variants, two aspect ratios, one superseded review export, two camera clips with the same original name, and a destination that requires a different final label. Ask a collaborator to locate a specified deliverable using only the guide and manifest.

Record ambiguities rather than scoring the person. If they choose the clean version instead of the captioned version, improve the variant labels. If they cannot identify the approved revision, improve the release record. If the filename becomes unreadably long, move a field into the manifest only after confirming it is not needed when the file travels alone.

The rehearsal is also a compatibility check. Copy the sample folder to the intended shared drive, compress and extract it, and open the editable project in the receiving environment. These are proposed checks; their success must be observed on your own tools. Do not declare a naming scheme portable simply because the text looks sensible.

Handle exceptions without abandoning the system

Some clients supply their own naming rules. Some platforms generate names you cannot control. Record the exception at the boundary rather than forcing the internal archive to match every external destination. Keep an internal identifier and a clear mapping to the delivered name.

If you inherit a messy project midway through production, resist a mass rename. Start the convention with new exports and create an index for existing files. Renaming everything may make the folder prettier while breaking the links people are actively using. A staged cleanup after a milestone is often easier to verify.

Review the guide when an exception repeats. Repeated manual work can reveal a missing field, but one unusual request does not justify adding three fields to everyone’s filenames. A good convention stays small because it distinguishes common needs from rare cases deliberately.

Release checklist

Before the next handoff, confirm that the filename identifies the asset and variant, its revision is unambiguous, and its extension matches the actual file type. Confirm that camera originals remain untouched, parallel concepts are not mistaken for sequential revisions, and the release manifest points to the exact approved export.

Then check the recipient’s view. Can they open the file? Does it have the expected captions, dimensions, and language? Does the manifest explain any renamed delivery copy? File naming supports these checks; it does not replace them. The system is successful when a collaborator can make the right decision without guessing what “final-final” meant.