Every creator has a folder like this somewhere: “final_v2_REAL_final_export(1).mp4”, a project file last opened in a version of Premiere nobody owns anymore, and a creeping certainty that the one video a client (or a brand, or your own channel) needs again is in there somewhere, unfindable.
Archiving sounds like admin for people with spare time. In practice it’s the difference between re-exporting a video in ten minutes next June and rebuilding it from memory over a weekend. A whole weekend. Because the file is “somewhere.”
Our projects carry more pieces than camera work does: storyboard images, generation batches from Seedance and Veo, Premiere projects, master exports, platform children, caption files, cover stills, prompts. Lose the thread between them and each piece becomes trivia. Keep the thread and the whole project stays rebuildable.
This guide lays out the archive system we actually maintain — what “complete” means per project, a storage plan sized for a solo creator, and the ten-minute ritual at delivery that makes future-you quietly grateful.
The Rebuild Test: Could You Re-Export This In June?
Judge every archive by one question: if this video needs re-exporting in six months (new platform spec, a repost, a compilation, a client revision), could you do it in under an hour without detective work?
Not “are the files somewhere on my drives.” Could you re-export?
The rebuild test breaks into four checks:
- Project opens. The Premiere project file exists, is the final version, and opens with its media linked or trivially relinkable.
- Media exists. Every generation, audio file, graphic and font dependency the project needs is inside the archive or in a library the archive points to.
- Decisions exist. The approved master, the cover still, captions, and any notes about what was approved (and what changed per platform) are present, so you rebuild the approved thing, not a plausible cousin.
- Names explain themselves. A stranger (future-you counts as a stranger — honestly, past-you is basically a stranger too) can tell what each file is without opening it.
Fail any one and the archive is a pile, not a system. The pile works fine until the first urgent request lands on a busy day, which is exactly when piles get searched.
Six months is the right horizon because it’s long enough to forget everything and short enough that it will definitely arrive. We’ve re-exported shorts for compilations, re-cut verticals for new surfaces, and revived pieces after platform spec changes. Every painless one passed the rebuild test. Every painful one failed it in a way this guide now exists to prevent.
What A Complete Archive Contains
A complete project archive, as we keep it, holds six groups. It looks like a lot written down and takes minutes to assemble at delivery, because most of it already exists — the ritual mostly moves and names things before they scatter.
- The project: the final Premiere project file (plus the last autosave if the finish was dramatic). Project files are small. Keep them like they matter, because they are the only file that remembers how everything fit together.
- Source media: every generated clip used in the edit (the selected generations, not necessarily every rejected render; more on that below), voice, music, SFX, images, and any phone or screen material, in the form the project links to.
- The plan: storyboard sheets and the final prompt set used for the generations. For AI work this is not nostalgia; prompts and seeds are how a shot gets regenerated or a series stays consistent months later.
- Masters: the fat master export of the finished video (and a master cover still), described fully in the next section.
- Platform children and captions: the exact files uploaded per platform, plus caption files (.srt or project caption exports) and any burned-in caption variants.
- Notes: one small text file. Title, platforms, dates, music source and licence note, anything non-standard (a replaced shot, a per-platform change), and your private-test fix-list outcomes. Ten lines that save ten emails.
One honest line on rejected material: archiving every render doubles storage and triples search pain. Keep generations that reached the timeline plus any serious alternate take, and let bulk rejects go after delivery. The storyboard and prompts preserve the ability to regenerate; the archive preserves what you chose.
Project, Masters, Platform Children, Captions
The exports deserve their own taxonomy, because most archive confusion is export confusion. We keep four clearly separated kinds of output, named so the kind is obvious from the file name:
Master. The fattest honest export of the final edit (1080×1920 at master bitrate for our vertical work), rendered once from the timeline and never edited, re-encoded or “quickly trimmed” afterwards. The master is the source for all future children. If a file has been uploaded anywhere, it is not the master; masters stay home. Keep the master cover still beside it.
Platform children. The exact files uploaded to TikTok, Reels, Shorts, Facebook, named per platform. These are evidence as much as deliverables: six months later, when someone asks what actually ran on Reels in March, the child file answers without an argument. Children are cheap to keep per project and priceless during disputes about versions. Priceless. I’ve learned that one the hard way.
Captions and text assets. The .srt (or platform caption file) per language and version, plus the title/description text in the notes file. Captions get reused (compilations, reposts, accessibility passes) far more often than creators expect, and regenerating them from scratch because the file lived inside one platform’s editor is a tax we stopped paying years ago. Where captions are burned in, the child file carries them and the notes say so.
Stills and covers. The approved cover still and any designed variant, as full-quality PNG plus the uploaded copy. Covers resurface for grids, compilations and press more often than any other still asset.
Why keep children if the master can regenerate them? Because regeneration takes the project opening cleanly, the preset still existing, and the platform spec not having moved — three assumptions that fail independently at the worst times. Children are the frozen record. Masters are the living source. Keep both, labelled, and version questions stop being questions.
This tiering mirrors how we think about delivery generally in multi-platform delivery specs: one source, explicit children, nothing derived from a platform’s copy.
Storage Tiers For Solo Creators
Archiving advice usually dies at the storage bill. A solo creator generating AI video daily produces serious weight: generation batches, masters, children. You don’t need enterprise storage. You need tiers matched to how often each thing is touched, plus one rule about copies.
Tier 1: working drive (fast, local). Current projects live here: active timelines, this month’s generations, renders in flight. Fast SSD, no ceremony. Projects move out when delivered, not when the drive begs.
Tier 2: archive drive (big, local). Delivered project archives, complete per the checklist above. Large, inexpensive spinning drives are fine here; archives are read rarely and written once. This is the library the rebuild test searches.
Tier 3: off-site copy (cloud or a second location). The archive’s insurance. Cloud storage for the full media archive can get pricey at generation-heavy volumes, so prioritise like it matters: project files, masters, children, captions, notes and prompts are comparatively small and absolutely irreplaceable; back those up off-site without exception. Bulky rejected generations are the first thing to leave behind if budget forces a choice. A drive at another address, updated on a rhythm, counts as off-site. A second folder on the same drive does not. (I know, that one hurts. But a flood doesn’t care about your partitions.)
The rule about copies: at least two copies of irreplaceable things, on different devices, with one off-site. Masters and project files are irreplaceable (rebuilding them is the weekend scenario). Platform children are technically re-derivable from masters — until the day they are the only record of what ran. Keep them backed up too; they are small.
Resist the urge to archive inside chat threads and downloads folders. A video in a messaging thread is a compressed copy on borrowed land. The archive is a place with an address: a drive, a folder structure, a backup. Our one clip, five formats projects show why: one edit becomes five deliverables plus captions and covers, and without tiers that family sprawls across three drives within a month.
Naming The Archive Like The Project
Naming is where archives succeed silently or fail forever. The goal: a file name that tells you the project, the kind of file, the platform or purpose, and the version — sortable by a computer and readable by a tired human at midnight.
Our pattern, kept deliberately plain:
- Project folder: date first, then a short project slug: 2026-10_glowing-fish-bath-ep08. Date-first means folders sort into a timeline of your work with zero effort, and the slug matches how the team refers to the piece.
- Master: glowing-fish-bath-ep08_MASTER_1080x1920.mp4. The word MASTER appears in every master we own, searchable across all drives in seconds.
- Children: glowing-fish-bath-ep08_tiktok.mp4, …_reels.mp4, …_shorts.mp4. Platform in the name, one file per platform, no ambiguity during posting.
- Captions: glowing-fish-bath-ep08_captions_en.srt. Language included even when you only have one language today. Future-you, subtitling for a new market, sends thanks.
- Cover and notes: …_cover.png and NOTES.txt inside the project folder. Notes are always the same name so your eyes learn one place to look.
Inside the project folder, five subfolders keep it navigable: 01_project, 02_media, 03_plan-storyboard-prompts, 04_masters, 05_platform-captions. Numbered so they sort in workflow order. Media may mirror your generation folders if clips are shared across projects; if so, the notes file states where shared originals live, and the archive keeps at least the timeline-used clips locally regardless. An archive that depends on five other folders staying put is a treasure map, not an archive.
Two naming sins to retire today: “final” as a versioning system (final, final2, REALfinal is a cry for help), and platform downloads saved as sources with names like a string of digits. Rename on arrival or do not save at all. Names are metadata for humans, and humans are the search engine your archive actually runs on.
The 10-Minute Archive Ritual At Delivery
Systems survive when they attach to a moment that already exists. Ours attaches to delivery — the moment platform children are exported and approved, while every file is still open, named in your head, and findable without searching. Ten minutes, same order every time:
- Freeze the project. Save the final project file. If a last-minute change happens after this, re-run the ritual for that change. The archived project must be the one that produced the approved master.
- Export (or confirm) the master and move it into 04_masters with its proper name, plus the master cover still.
- Gather the children and captions exactly as uploaded (or about to be) into 05_platform-captions, renamed to pattern. Upload from these files so the archive and the platforms agree.
- Copy the plan: storyboard sheets and final prompts into 03_plan. For series work, this folder is gold; episode nine’s consistency starts here.
- Collect used media into 02_media (Premiere’s project consolidation tools, such as Project Manager where available, can gather used files; verify the result rather than trusting it blindly). Check the relink by closing and reopening the archived copy once. Two minutes that prove the rebuild test passes while fixing it is still easy.
- Write NOTES.txt: title, date, platforms and posting dates, music source, caption languages, quirks, test-upload findings worth remembering. Short, factual, done.
- Move the folder to the archive drive and queue the off-site sync for the irreplaceable parts. Deleting working-drive bulk (rejected generations) happens here, deliberately, while you can still see what the project used.
Run it while the delivery energy is still in the room and it costs ten minutes. Run it “later this week” and it costs an hour of re-finding things, which is why later-this-week archives quietly never happen.
Tie it to the upload, make it the step that earns the word “done”, and the system runs itself. It also closes the loop with your AI video QC checklist: checks approve the video, the ritual preserves it, and together they mean a published short stays publishable forever.
Frequently Asked Questions
What Should I Keep When Archiving A Video Project?
Keep six groups: the final project file, the media used in the edit, the plan (storyboards and final prompts for AI work), the master export plus master cover still, the exact platform files uploaded with caption files, and a short notes file covering platforms, dates, music and quirks. Keep generations that reached the timeline plus serious alternate takes; bulk rejects can go, since prompts and storyboards preserve the ability to regenerate.
Do I Need To Keep Platform Exports If I Have The Master?
Yes. The master lets you make new children; the saved children are the frozen record of what actually ran on each platform, including burned-in captions and per-platform variants. They are small, they settle version questions instantly, and they save you when a project no longer opens cleanly. Master is the source, children are the evidence. Keep both, named by platform.
How Should I Name Video Files And Folders?
Date first, then a short slug for the project folder (like 2026-10_project-name). Put the kind in every file name: project_MASTER for masters, project_tiktok / project_reels / project_shorts for children, project_captions_en.srt for captions, project_cover.png for covers, and a NOTES.txt in every folder. Retire “final_v2_REAL” naming. If a tired stranger cannot identify a file from its name, rename it at delivery.
Where Should I Store My Video Archive?
In tiers. Current projects on a fast working drive, delivered archives on a large local archive drive, and an off-site copy (cloud or a drive at another location) for the irreplaceable parts: project files, masters, children, captions, notes and prompts. Keep at least two copies on different devices with one off-site. Do not treat platform downloads or chat threads as storage; those are compressed copies on borrowed land.
Future-You Says Thanks
Nobody archives for the good days. You archive for the June afternoon when the request lands (“can we repost that one, new spec, today?”) and the answer gets to be “give me ten minutes” instead of a sigh and a rebuild.
Masters labelled, children frozen, plans kept, names that explain themselves: that is the whole system. It is not glamorous. Neither is a spare tyre, right up until the moment it is the most valuable thing you own.