Build one governed shared library with two distinct areas: a reusable, approval-controlled asset vault and self-contained project workspaces. Give every asset an identifier, a clear status, an owner, and a defined final-master location. This lets editors reuse approved material without mistaking copies, drafts, or platform exports for the source of truth.
The objective is not a perfect folder tree. It is a system that answers four questions quickly:
- Is this asset approved for use?
- Where is the editable source?
- Who can change it?
- Which file is the current approved deliverable?
Create Two Library Zones
Separate assets that are meant to be reused from assets that only belong to one production. Mixing them is how a temporary campaign graphic becomes a "brand template," or an old music track quietly reappears in a new edit.
Use a top-level structure like this:
01_Reusable_Approved
├── Brand
│ ├── Logos
│ ├── Fonts
│ ├── Brand_Guidelines
│ └── Approved_Graphics
├── Music_SFX
├── Motion_Templates
├── Stock_and_Licensed_Media
├── Captions_and_Copy_Blocks
└── Rights_and_Approval_Records
02_Active_Projects
└── Client_or_Brand
└── Campaign
└── Project
├── 01_Brief_and_Scope
├── 02_Source_Media
├── 03_Proxies
├── 04_Project_Files
├── 05_Review
├── 06_Masters
└── 07_Platform_Deliveries
03_Archive
├── Completed_Projects
└── Retired_Reusable_Assets
What Belongs in the Reusable Library
The reusable zone is for assets that have an owner, an approval state, and a realistic reason to be used again. Typical examples include approved logos, licensed music, sound effects, motion templates, recurring lower-thirds, stock footage, and brand guidance.
Do not copy these files into every project by default. Instead, point editors to the governed library item or include a documented project copy only when the workflow requires one. A copied logo is harder to retire when branding changes; a copied music file is easier to reuse after its license has expired.
What Belongs in a Project Workspace
A project workspace should be self-contained enough for an editor to continue work without guessing where campaign-specific material lives. Keep raw footage, proxies, edit files, review exports, approved masters, and delivery files together under the client, campaign, and project path.
Use client, campaign, and project as the main navigation path. Treat shoot date, camera, content type, talent, locale, and platform as secondary folders or searchable fields-not competing top-level systems.
For example, footage can sit under 02_Source_Media/2026-07-15_ShootDay01/Camera_A, while its project still remains easy to find through the campaign path.
Use Identifiers, Statuses, and a Small Tag Set
A filename should identify a file. It should not attempt to hold every detail someone may later search for.
Use a consistent pattern such as:
Client_Campaign_AssetName_Ratio_v##_Status.ext
For example:
Northstar_SpringLaunch_HeroCut_9x16_v03_ClientReview.mp4Northstar_SpringLaunch_HeroCut_16x9_v04_ApprovedMaster.movNorthstar_SpringLaunch_ProductCloseup_A001_Raw.mov
This pattern makes the asset, intended framing, revision, and workflow state visible at a glance. Version names can usefully encode aspect ratio, revision number, and status, but the exact syntax is less important than team-wide consistency.
A compact taxonomy can distinguish source role, review status, and delivery format without forcing every detail into filenames. For timeline work, markers and labels can separate moments, tasks, categories, and revision states. Apply the same logic across your storage structure: markers identify where a change belongs; labels classify what an asset is or whether it is ready.
Apply Only Metadata That Changes a Decision
Require tags only when they affect reuse, editing, approval, or delivery. A practical minimum includes media role (such as A-roll, B-roll, graphics, audio, or captions) and approval status. Avoid asking editors to catalog every visual attribute during ingest. If metadata does not change a decision, it becomes administrative work that will eventually be skipped.
For footage-heavy projects, keep a selects timeline separate from the active assembly. That gives editors a place to assess chosen takes without cluttering or destabilizing the final edit.
Govern Reuse with Ownership and Rights Records
A file can be technically accessible and still be unusable. Access does not establish that a logo is current, a music track is licensed for a channel, or a template is creatively approved.
Assign an owner to each zone:
Keep the approval or license record beside the reusable asset record, not only in an email thread or a person's memory. For restricted media, include the applicable usage condition in the asset record: expiry, territory, paid versus organic use, client limitation, or platform restriction.
Set archive triggers before the library becomes crowded. Archive a project when its approved deliverables are complete and its revision window has closed. Deprecate reusable assets when brand, rights, or creative approval changes. Never overwrite a deprecated asset with a new one; preserve the old item's record and publish a separately identified replacement.
Permission behavior depends on the storage platform. For example, moving files into a Google shared drive changes ownership from an individual owner to the organization, and a folder move can also alter inherited access. Review membership and direct sharing before and after migration using Google's shared-drive migration guidance. Treat this as a storage-specific check, not a universal permission rule.
Prevent Overwrites with an Explicit Handoff Protocol
Folder names alone do not stop two editors from changing the same project file. Your team needs a defined handoff routine, especially when editors are working on related versions or platform adaptations.
Use this four-step protocol:
- Assign one editor-owned working file. Name it clearly, such as Northstar_SpringLaunch_Edit_JLee_v05_WORKING.
- Publish a frozen review version. Export the review copy to 05_Review and do not continue changing that exact version while feedback is being collected.
- Record feedback as actions. A note such as "fix this" creates interpretation work. Use instructions such as "AUDIO: lower music under voiceover at 00:14" or "CTA: replace ending for 9x16 version."
- Create the next revision rather than replacing the reviewed file. Move forward to v06, document what changed, and preserve the reviewed export as part of the decision trail.
Markers are useful for pointing to a specific moment or range in an edit. Labels are better for classifying clips, versions, or statuses. Neither is a legal approval record or a substitute for project locking, backup, relinking, or recovery safeguards in the team's chosen tools.
Before final export, run one focused editorial pass for captions, audio, crop safety, product details, and CTA accuracy. This is particularly important when a horizontal master becomes a vertical or square adaptation.
Keep One Master Above Platform Variants
Treat 9:16, 1:1, and 16:9 versions as distinct deliverables. They are not replacements for the approved master.
A clear delivery structure looks like this:
06_Masters├── Northstar_SpringLaunch_Master_16x9_v04_APPROVED.mov├── Northstar_SpringLaunch_Master_Audio_APPROVED.wav└── Northstar_SpringLaunch_Captions_Source_APPROVED.srt07_Platform_Deliveries├── YouTube_16x9│ ├── Video│ ├── Thumbnail│ ├── Captions│ └── Publish_Record├── TikTok_9x16│ ├── Video│ ├── Cover│ ├── Captions│ └── Publish_Record└── Instagram_9x16 ├── Video ├── Cover ├── Captions └── Publish_Record
Each platform folder should retain the platform-specific video, caption file, cover or thumbnail, approved copy, and delivery or publishing record. This prevents a social export from becoming the accidental master simply because it was easiest to find.
Label adaptations explicitly: 9x16, 1x1, and 16x9 are clear, portable identifiers. Verify current technical requirements, duration limits, advertising rules, and upload settings directly with each platform before delivery; those requirements can change independently of your library structure.
Roll Out the System on One Active Campaign
Do not reorganize years of media at once. Start with one active campaign and standardize the highest-risk areas first:
- Approved logos, music, and templates
- Project source-media locations
- Editor-owned working versions
- Review exports and change records
- Approved masters and platform variants
Assign one person to own reusable approvals and one person to own project archival. Test whether every editor can find the correct source, identify the current review version, and locate the approved master without asking in chat.
Once the team can reliably find, reuse, review, and export assets from that pilot structure, expand it across the rest of your storage environment.