export const meta = {
title: "Video Project Folder Structure for Teams: A Template from Ingest to Archive",
description: "Use a reusable video project folder template with naming rules, intact camera cards, clear handoff owners, shared paths, and an archive checklist.",
tldr: "Give every production one stable project root, preserve complete camera-card copies, and separate originals, working media, project files, review exports, and deliveries. Assign someone to verify each handoff, then use metadata and collections to find and present files without moving the originals your editing software references.",
slug: "video-project-folder-structure-for-teams-a-template-from-ingest-to-archive",
publishedAt: "2026-10-30",
readingTime: 10,
thumbnail: "https://cdn.aspectlabs.dev/blog/video-project-folder-structure-for-teams-a-template-from-ingest-to-archive/cover-be5f734ef456.png",
authors: ["gurish"],
primaryTopic: "post-production",
topics: ["post-production", "technical-solutions"],
tags: ["media-management", "data-management", "camera-media", "team-access", "archive"],
faq: [
{
question: "What folders should every video project contain?",
answer: "Start with administration, originals, editing media such as proxies, supporting assets, project files, review exports, final deliveries, and archive records. Keep the same top-level names across productions, but create department-specific subfolders only when the work needs them. Original camera-card contents should remain together inside uniquely named card folders."
},
{
question: "Should I rename camera clips to match the project naming convention?",
answer: "Preserve camera-generated filenames and the complete card structure unless your camera and editing workflow explicitly support a tested change. Rename the containing production, shoot-day, camera, and card folders instead. Moving only video files or separating sidecars can lose relationships that the camera format or editing application depends on."
},
{
question: "Should proxies be stored beside camera originals?",
answer: "Keep generated editing proxies in a separate, predictable directory and retain enough of the source hierarchy to distinguish identical clip names from different cards. Attach them through the editing application's proxy workflow. Check timecode, frame rate, duration, and audio layout before treating a viewing copy as an editing proxy."
},
{
question: "Does a folder called Approved or Client protect the files inside it?",
answer: "No. A folder name describes your intention, while permissions determine access. In Aspect, a workspace member's project role applies throughout that project's content. Use appropriate project boundaries and configure guest share links for the specific files or collections each recipient needs."
},
{
question: "How can the same footage appear in several selects groups without duplicate files?",
answer: "Use collections for curated groups and metadata for searchable facts such as subject, location, or usage restrictions. An Aspect collection points to assets in their existing locations, so a clip can appear in several collections without being moved or copied. Confirm the collection's contents and sharing settings before giving another person access."
},
{
question: "Should I move a completed project into an Archive folder?",
answer: "Avoid changing working paths merely to mark a project complete. Record the final project version, dependencies, delivery manifest, retention decision, and recovery procedure first. If the files need to move, verify the retained copy and reopen the project from its new location before releasing the working copy."
}
],
draft: false
}
When another editor joins your production, they need to find the source footage, current edit, and approved deliveries without asking who last worked on it. Use the same top-level folders across projects, and keep the source paths stable so an edit still opens when the client requests a revision six months later.
The template below uses a two-day campaign shoot, `P026_RIVER_LAUNCH`, to show how a small production team with several deliverables can organize ingest, editing, review, delivery, and archive files. Productions organized around seasons and episodes can use the separate [guide to folder structures for multi-season TV shows](https://aspect.inc/blog/post-production/guide-to-folder-structures-for-multi-season-tv-shows) for that additional hierarchy.
## Start with one stable project root
Choose a permanent project identifier before the first import. A campaign's public title may change; the identifier should not. In this example, `P026` identifies the production and `RIVER_LAUNCH` makes it recognizable to people browsing storage.
Copy this tree into the project's setup notes and create the directories your production needs. The `original_card_contents` entries describe where complete card copies belong; they're placeholders, not extra folders to insert into the camera's own structure.
```text
P026_RIVER_LAUNCH/
00_ADMIN/
README.txt
INGEST_REPORTS/
DELIVERY_SPECS/
HANDOFF_NOTES/
01_ORIGINALS/
CAMERA/
2026-09-14/
CAM_A/
A001/
original_card_contents
A002/
original_card_contents
CAM_B/
B001/
original_card_contents
2026-09-15/
AUDIO/
2026-09-14/
RECORDER_01/
2026-09-15/
02_EDITING_MEDIA/
PROXIES/
2026-09-14/
CAM_A/
A001/
A002/
CAM_B/
B001/
SYNCED_DAILIES/
03_ASSETS/
GRAPHICS/
MUSIC/
SOUND_EFFECTS/
STOCK/
LOOKS/
04_PROJECTS/
EDITING/
GRAPHICS/
COLOR/
SOUND/
HANDOFF_PACKAGES/
05_REVIEW/
MAIN_60S/
SOCIAL_15S/
06_DELIVERY/
MASTERS/
SOCIAL/
CAPTIONS/
DELIVERY_MANIFEST.txt
99_ARCHIVE_RECORDS/
DEPENDENCIES.txt
RETENTION.txt
RECOVERY_NOTES.txt
```
The numbered prefixes keep the main directories in the same order. They don't mean media should move from one directory to the next as work progresses. Originals remain in `01_ORIGINALS`; an export is a new file with a different purpose and belongs in review or delivery.
Keep `00_ADMIN` to information that everyone with project access may see. Store restricted contracts or personnel information in an appropriately restricted system or separate project. A directory named `PRIVATE` provides no protection by itself.
`04_PROJECTS` holds supported project files, exports, and handoff packages. If the editing application stores its live project in a database or cloud service, leave it there. Record that location in the README and save project exports or backups in `04_PROJECTS`. Don't relocate a live application database merely to make it fit the tree.
## Preserve the camera card before organizing its footage
Give each card a unique containing directory using the shoot date, camera identity, and card number. This prevents two cameras' `C0001` clips from colliding without changing either clip's original name. Preserve everything beneath that directory, including metadata, sidecars, indexes, and any subfolders created by the camera.
Adobe's [guidance for transferring file-based media](https://helpx.adobe.com/premiere/desktop/organize-media/transfer-files/transfer-assets-from-file-based-media.html) specifically recommends copying the entire folder with all subfolders to retain the original structure. A camera recording can depend on relationships that are invisible when you look only at its video files. Treat the complete card copy as the unit of ingest, and use the appropriate import workflow for the format.
The person handling ingest should verify the copy before the editor starts working with it. Record the source card identifier, destination, file count, verification result, operator, and any exceptions in `INGEST_REPORTS`. Use a copy tool that checks transferred data against the source, and retain its report. A matching file count alone doesn't establish that every byte transferred correctly.
For the example shoot, the assistant editor accepts `A001` only after the report is complete and clips from the beginning, middle, and end of the card open correctly. They then import from its permanent location. A card may need temporary receiving storage during transfer, but the editor shouldn't import from that temporary path and depend on moving the files during cleanup.
Aspect's [folder upload workflow](https://aspect.inc/docs/getting-started/uploading-and-organizing) preserves nested directory structure. After uploading, confirm transfer completion and reconcile the received files with the ingest inventory before treating the cloud copy as ready for the next person.
## Use filenames to identify files that leave the folder
When you export a file for a client, its parent folder may not travel with it. Name team-generated files so their identity survives that handoff. Use a small, documented vocabulary rather than allowing each editor to invent abbreviations.
For the campaign example:
```text
P026_MAIN_60S_EDIT_v012.prproj
P026_MAIN_60S_REVIEW_v012_2026-09-21.mp4
P026_MAIN_60S_MASTER_3840x2160_23976p_v013.mov
P026_SOCIAL_15S_1080x1920_2997p_v004.mp4
P026_MAIN_60S_EN-US_CAPTIONS_v013.srt
```
The project code and deliverable identify the work. The purpose distinguishes an editing project, review copy, master, or caption file. A padded version number such as `v013` sorts consistently and provides a reference that survives email, downloads, and archive retrieval. Define frame-rate tokens such as `23976p` and `2997p` in the README so recipients know they mean 23.976 and 29.97 progressive frames per second.
Use `YYYY-MM-DD` for dates, and specify what each date represents. Here, the review date is the export date; the shoot date remains in the original-media hierarchy. Avoid punctuation that conflicts with paths, and keep filenames short enough to read in editing applications and transfer tools.
Reserve these rules for files the team creates. Leave camera-generated names intact. Give proxies a source mapping that includes the card identity, and use the editing application's supported naming and attachment workflow. A smaller MP4 is suitable as an editing proxy only after its timecode, frame rate, duration, and audio layout have been checked against the original.
A version number also doesn't express approval. `v013` may still need changes, and a later revision may invalidate a previous decision. Record the approved revision explicitly instead of accumulating names such as `FINAL_FINAL_NEW`.
## Assign an owner to every handoff
Assign someone to check each handoff. Without that agreement, several people can put files in the right folders while each assumes someone else checked the contents. On a small job, you may fill several roles, but the rest of your team should know who confirms that an upload, edit, or delivery is ready.
| Stage | Responsible owner | Condition for the next handoff |
| --- | --- | --- |
| Ingest | Data wrangler or ingest operator | Complete card copies and verification reports are available. Exceptions are documented. |
| Preparing the edit | Assistant editor | Imports, audio, source paths, and any proxy attachments have been checked. |
| Editing | Assigned editor | The current project or published changes are saved, and collaborators know who can edit next. |
| Review | Producer | Reviewers receive the intended revision, and the decision identifies that revision. |
| Delivery | Finishing editor and producer | Export checks pass, required files are listed, and the approved delivery is confirmed. |
| Archive | Media operations owner | Dependencies, retention decisions, access, and the recovery procedure are recorded. |
For a shared project file, a handoff includes saving, closing when required, waiting for synchronization, and telling the next editor which file to open. For an application with its own collaboration system, use that system's publish, locking, or handoff controls. Shared storage provides common files; the editing application controls how people work on the edit together.
Keep machine-specific media caches and disposable render caches on suitable local storage according to the application's guidance. They can consume substantial space and usually don't belong in a general client handoff. Distinguish these rebuildable files from generated media actually referenced by a timeline, which must remain available or be replaced through a documented workflow.
## Keep shared paths consistent as editors join
A correct filename doesn't prevent offline-media errors if each workstation sees a different location. Record the intended mount root and folder hierarchy in `README.txt`, and check them on a second workstation before a large import. Avoid importing from personal Downloads folders or temporary external drives when the shared copy is the intended source.
In Aspect, [mount the project](https://aspect.inc/docs/instant-access/mount-a-project) through the desktop app on macOS or Windows and import from that drive. Record the mount path for each operating system, then open a sequence containing the video, audio, graphics, and proxies your team uses. Follow the [Premiere Pro workflow](https://aspect.inc/docs/workflows/premiere-pro) for the separate project settings used by individual projects, Productions, and Team Projects.
Aspect mounts a project as a drive on macOS and Windows, preserving its folders so editors can open the media directly in their editing applications. Keep imports pointed at that drive, and the same folder template can serve the team from the first assembly through the finishing handoff.
Renaming a card directory after import can still change a referenced path. If a correction is necessary, have the owner plan it, pause affected work, preserve a recovery copy, relink in the relevant applications, and verify the handoff before everyone resumes. Tell collaborators which paths changed before they reopen their edits.
## Use metadata and collections for overlapping categories
Folders work well for an asset's stable home. They become awkward when a single clip is simultaneously an interview select, a product shot, and an option for three different cuts. Creating a physical copy for each category introduces several files to maintain and makes it harder to identify the source.
Put those overlapping facts in [project metadata](https://aspect.inc/docs/workflows/metadata). A practical starting set is subject, shoot location, intended deliverable, usage restrictions, and review status. Use defined select options where consistency matters, and assign a person to maintain each operational field. Rights status should come from checked licensing information; a searchable label does not itself authorize reuse.
When you need to gather selects for an editor or client, create a collection. In the example project, `INTERVIEW_SELECTS` can reference clips from both shoot days while `SOCIAL_OPTIONS` references some of the same clips. The physical card folders remain unchanged, and the editor continues to use the original source paths.
Aspect collections gather assets from different folders without moving or duplicating their originals, and an asset can belong to several collections. That lets a producer prepare interview selects and a client review collection from the same footage while the editor's existing folder organization stays intact.
Configure access separately. An Aspect workspace member's [project role](https://aspect.inc/docs/share-and-present/sharing-and-permissions) applies throughout the project. When a collaborator must not see some material, choose an appropriate project boundary or a guest link to selected content; placing it in a different folder within an accessible project does not reduce that person's project role.
## Separate review history from delivery and archive records
Keep review exports under the relevant deliverable in `05_REVIEW`. In Aspect, [version stacks](https://aspect.inc/docs/review-and-approve/versioning) group related review revisions and retain comments with their respective versions. Confirm which revision appears by default before sharing. Stacking review cuts is separate from backing up a working project file.
The producer records the approved revision and the finishing editor checks the exact files entering `06_DELIVERY`. The delivery manifest should list filenames, versions, dimensions, frame rates, audio requirements, captions, and the approval reference. If the team uses Aspect's [custom approval-status field](https://aspect.inc/docs/review-and-approve/approvals), update it deliberately: approving a comment and changing that field are separate actions.
At closeout, preserve the project and the dependencies needed to reopen it. Record application versions, plug-ins, fonts or font requirements, external library locations, original-media locations, and any accepted missing elements. Record the backup locations and retention owner in `99_ARCHIVE_RECORDS`; that directory documents recovery and doesn't constitute another backup merely because it is named for archiving.
Before releasing working storage, have someone follow the recovery notes to reopen the retained project. Play a sequence containing the camera formats, graphics, effects, and audio used in the final delivery. Keep the original structure stable unless the archive plan requires a verified migration. Review access at closeout and remove any guest links or project memberships that are no longer needed.