Every feature carries two organizational systems at once. One lives inside the editing application and reflects how a cutter thinks. The other lives on disk and reflects how an entire post-production department exchanges material. Confusing the two is where turnovers start bleeding time.
Storage Hierarchy Versus Bins: What Each One Governs
A feature film folder structure is the storage-level hierarchy used to locate, protect, exchange, and archive editorial material throughout post-production. It governs files, not opinions about the cut. Editorial, sound, visual effects, graphics, and delivery all read from it, and each department owns identifiable branches within it.
The distinction matters because the two systems have different lifespans. A storage path such as 02_DAILIES/2026-08-17/A_UNIT/CAMERA_ORIGINALS stays meaningful when it is copied to a shuttle drive, listed in a manifest, or opened by a sound editor who has never seen the timeline. A bin called Scene 24 Selects exists only inside its project or library. Bins organize a point of view. Directories organize an asset base.
Standardization here means adopting one documented production template, approved before ingest, then reusing it without renaming established branches. It does not mean a single universal layout exists for every studio, facility, or picture. The post-production supervisor approves the template; department leads confirm which branches they own; the root is copied once and reused for new storage volumes and turnover packages.
Where Turnovers Come Apart: FINAL_NEW_2 and Other Traps
Consider a folder sequence containing FINAL, FINAL_NEW, and FINAL_NEW_2. Nothing in those three names carries approval order, and modification timestamps shift during copying, so the sequence cannot be reconstructed from the filesystem. A sequence of v001, v002, v003 preserves an explicit order that survives transfer.
The same ambiguity shows up in placement. A review movie parked beside active project files can be mistaken for project support media, omitted from a turnover, or deleted during cleanup, because its operational status was never declared by its location. Camera media mixed with editorial transcodes creates the same class of problem: two things with completely different retention rules sitting in one folder.
Where handoff reviews on features trace each requested asset back from the receiving department's manifest to its stored source, one pattern repeats: any path that depends on knowing who created a folder, or which week it was created, is already broken. Inconsistent capitalization, free-form dates, and improvised reel labels make searching and relinking unreliable long before anyone notices.
Local storage tolerates experimentation. A private scratch folder can be as messy as its owner likes. Shared storage needs stable names, controlled write access, and locations that every department can describe from memory.
Rename With Care
Renaming 02_DAILIES/2026-08-17/A_UNIT after clips have been linked can invalidate every stored path beneath that directory, including camera originals, synchronized audio, reports, and transcodes. Branch names are set once, at template approval.
Confirm the Production Code Before the First Camera Card Lands
What has to be settled before media arrives? The root name, first. It becomes the string embedded in paths, manifests, and exchange packages, so it should come from the approved show code rather than a working title likely to change after photography begins. RIVER_47_POST survives a title change; UNTITLED_SUMMER_PROJECT does not.
Next comes classification by operational state rather than by department politics. Immutable sources, working files, review exports, formal turnovers, and approved deliverables each get their own territory, because each one has different write permissions and different retention consequences.
Two practical rules follow from that. Each camera card is preserved as a complete directory under its shoot date and unit, including metadata, sidecar files, and the card's original internal hierarchy, rather than a harvest of visible picture clips. Production sound stays under the matching dailies date and unit, while ADR, music, effects, incoming sessions, and mixes live under the audio post branch.
Numbered top-level folders from 00 through 07 sort in the same operational order across common shared filesystems, and 99_ARCHIVE stays visibly separated at the end of the list where nobody mistakes it for working storage.
The Baseline Root: 00_ADMIN Through 99_ARCHIVE
A workable baseline root contains nine branches: 00_ADMIN, 01_EDITORIAL_PROJECTS, 02_DAILIES, 03_AUDIO_POST, 04_VFX_GRAPHICS, 05_EXPORTS, 06_TURNOVERS, 07_DELIVERABLES, and 99_ARCHIVE. An assistant creates the root from a read-only master template, confirms every required branch exists, and records the template revision in the root README.
00_ADMIN holds CURRENT_CONTACTS, WORKFLOW_NOTES, NAMING_RULES, SCHEDULES, and README files. Access-controlled production records stay outside broadly readable documentation folders; a naming guide and a cast contract do not belong to the same permission class.
01_EDITORIAL_PROJECTS separates ACTIVE, EXCHANGED, TEMPLATES, and MANUAL_BACKUPS. A manual snapshot can read as SHOW_EDIT_2026-08-18_1845_v037. Application-managed autosaves remain wherever the software has been configured to protect them, which is often local or managed storage rather than the shared volume. The README has to say which of the two a receiving assistant is looking at.
Dailies nest by date, unit, camera, and roll: 02_DAILIES/2026-08-17/B_UNIT/CAM_B/B014/CAMERA_ORIGINALS, with sibling locations for PRODUCTION_AUDIO, REPORTS_METADATA, and EDITORIAL_TRANSCODES. 03_AUDIO_POST carries ADR, MUSIC, SFX, EDITORIAL_TURNOVERS, INCOMING_SESSIONS, REVIEW_MIXES, and APPROVED_MIXES.
One scope note before anyone treats this as doctrine: studio security rules, contractual delivery specifications, and the host facility's storage policy take precedence over any baseline template, including this one. Coursework in post-production workflow at Video Symphony, the training provider at 731 N. Hollywood Way, has long framed directory design as a negotiated document rather than a fixed diagram, and that framing holds on set.
Naming Rules That Survive Leaving Their Folder
The test for a filename is simple: does it stay unique and legible after it leaves the folder that currently explains it? Editorial proposes the shortest name that passes, checks it against sound, VFX, graphics, review, and delivery systems, and the supervisor approves the token order.
A compact pattern is PROJECT_ASSET_DEPARTMENT_v###_YYYY-MM-DD.ext, for example R47_SC012_EDIT_v006_2026-08-18.mov. Dates in YYYY-MM-DD sort correctly by machine and read correctly by humans in every territory.
Camera and sound identifiers assigned in production reports, such as A014, B014, or SR023, are preserved exactly. Translating them into editorial-only labels breaks the chain back to the report that documents them.
Pad the Version Token
Versions start at v001 and stay padded, so lexical sorting never drops v10 ahead of v2. APPROVED is appended only after an authorized reviewer records acceptance. FINAL replaces nothing and distinguishes no later correction.
Names exclude slashes, colons, trailing spaces, and decorative symbols. Path length gets measured on the actual transfer and receiving systems, since the editorial workstation is the most forgiving machine in the chain.
The Mock Turnover Rehearsal, One Working Day Before First Ingest
Reserve roughly a two-to-four-hour block at least one working day before the first scheduled ingest. One assistant assembles a mock package; a second assistant, working only from the README and the manifest, locates, relinks, exports, and repackages the material without verbal guidance.
The package should include one complete representative camera-card copy, one matching production-audio roll, one dated manual project backup, one VFX pull with reference media, one sound turnover, and one review export.
The receiver verifies read and write access separately for 01_EDITORIAL_PROJECTS, 05_EXPORTS, 06_TURNOVERS, and the restricted 07_DELIVERABLES branch. The deepest expected path is tested on every transfer target. Scratch render locations are confirmed to sit outside protected deliverables. A package that relinks perfectly on the originating workstation can still fail at sound or VFX when it carries an absolute path to a private scratch volume, so the relink is performed after opening the project from the handoff location.
Verify, Then Delete
Each handoff is copied and verified against its recorded checksums before the source copy is removed. Correct folder placement is organization, and organization is not media verification or a substitute for the production's backup policy.
Failures from the dry run get logged, corrected in the master template, and retested inside the same reserved block. That is the cheap version of the problem.
So here is the question worth answering before the first card arrives: if the assistant who built your root is out sick on the day sound requests a turnover, can the person who replaces them find every asset using only the README and the manifest?
Your Thoughts
No comments.
Share Your Opinion