
A naming and tracking system for AI video production, borrowed from a hundred years of film pipeline discipline that the AI tools never inherited. Three weeks into producing Lost Garden, my corridor scene folder had 214 files in it. corridor_v2.mp4. corridor_v2_ACTUAL.mp4. corridor_FINAL_use_this_one.mp4. Not one of those names told me which prompt, which seed, or which of three separate generation attempts had made it. I had to open each file and watch it to remember what it even was. That is not a personal failure of organization. It is what happens by default when a tool lets you generate twenty variations of a shot in the time it used to take to set up one camera angle. A file naming and tracking system for AI-generated video needs to capture four things a traditional camera shoot never had to worry about: a scene and shot ID, a variant number for the pile of near-identical takes, a version tied to a specific prompt and seed, and a short log connecting all of it back to the settings that made it. Something as plain as lg_s02_sh014_var07_v02 tells you more at a glance than a folder full of files called “final.” Why AI video breaks the naming systems everyone already has Film and animation production solved this problem decades ago, just not for this volume. Netflix’s own VFX shot and version naming guide lays out the standard: a show ID, episode, scene, and shot number assigned once by editorial, then a version suffix per department pass, zero-padded so v1 becomes v001. It works because the shot count is fixed early and stays fixed. Editorial decides there are, say, 800 shots in the film, and everyone downstream names things against that list. AI generation throws out that assumption in one specific way: the shot count is never fixed, because generating another take is nearly free. Where a traditional VFX shot might see two to five versions on its way to final, a single AI-generated shot commonly goes through 20 to 50 variations before one of them holds up, a number that matches what most solo AI filmmakers report once they are running a real production instead of a demo. A 20-shot short can quietly produce 400 to 1,000 individual clips before you have even picked your favorites. A few things are genuinely new here, and none of them show up in a traditional naming guide: There is no editorial department assigning shot numbers up front. You are inventing the scene and shot structure as you go, often changing it mid-production. The variant count is not a handful, it’s dozens , and most of them look close enough to each other that a filename has to do the disambiguating your memory can’t. The prompt and seed are now part of the shot’s identity , the same way a lens choice or a take number used to be, except nothing in a normal file browser captures either one. What’s a good file naming convention for AI-generated video clips? Adapt the VFX pattern instead of inventing a new one. A workable structure looks like: [project] [scene] [shot] [variant] [version].mp4 For example: lg_s02_sh014_var07_v02.mp4. That’s the Lost Garden project, scene 2, shot 14, the seventh generated variant, second edited version of the one you kept. Every field is zero-padded (sh014, not sh14) so the files sort correctly once you pass shot nine. A filename that needs a video player to decode is not a filename. It’s a guess with a play button. The point isn’t the exact format, it’s that every field answers a question you would otherwise have to reopen the file to ask: which project, which scene, which shot, which one of the pile, and which pass of editing. How should you structure folders for an AI video project? Structure folders by scene and shot , not by date and not by which tool made the clip. A folder tree organized by generation date tells you nothing six weeks later; one organized by scene and shot still makes sense a year from now. A structure that holds up in practice: 01_scenes/scene02/shot014/generations/ for every raw variant, no exceptions 01_scenes/scene02/shot014/approved/ for the one or two that made the cut 01_scenes/scene02/shot014/rejects/ for everything else, kept rather than deleted That last folder matters more than it sounds like it should. A reject from three weeks ago is sometimes exactly the establishing shot a later scene needs, or the evidence for why a particular prompt phrasing doesn’t work with a given model. Deleting rejects the day you generate them means re-learning the same lesson twice. How do you track which prompt, seed, and model made each clip? A naming convention tells you what a file is. It doesn’t tell you how to make another one like it, or a better one. That needs a log, and it can be as unglamorous as a spreadsheet with one row per generation: filename model and version (models change silently; “Kling” is not enough, “Kling 3.0, generated June” is) seed prompt text, or a pointer to the prompt file date status: candidate, approved, or rejected, and why This is the step almost every beginner skips, because for the first ten clips it feels like overhead you don’t need. By clip forty it’s the only thing standing between you and re-generating a shot you already solved, because you can no longer remember which of six near-identical attempts was the one that worked. Common mistakes worth naming directly Naming by mood instead of shot ID. moody_take_2.mp4 describes a feeling, not a location in your production. It tells you nothing once you have thirty files that all felt moody. Deleting rejects immediately. The instinct is to clean up. The cost is losing the record of what you already tried. Keeping the log in your head. It works until the day you stop working on the project for two weeks and come back to a folder that no longer makes sense to you either. Not versioning the prompt itself. Prompts get tweaked mid-session more often than people admit, and the version that produced the keeper is rarely the one saved in your clipboard history. A better place for all of it to live None of this requires special software. A naming convention and a spreadsheet get you most of the way, and that’s a legitimate place to stop if a spreadsheet is what you’ll actually keep updating. Where it breaks down is when the shot ID, the prompt log, and the reference images for that scene live in three different apps that don’t talk to each other. That’s the specific gap I built ScreenWeaver to close: the scene, the shot, the reference stills, and the generation history sit next to each other instead of split across a file browser, a spreadsheet, and whatever chat history holds your actual prompts. After I put a version of this system in place on Lost Garden, the corridor scene folder stopped being 214 mystery files and became twelve shots with a clear approved take and a labeled pile of attempts behind each one. Retrieval time for “wait, which prompt made that” went from re-watching four files to reading one row in a log. FAQ Do I need special software to start doing this? No. A shared spreadsheet and a consistent folder structure cover the essentials. Add dedicated tooling once the spreadsheet itself becomes the bottleneck, not before. I already have hundreds of unorganized clips. Where do I start? Don’t try to rename everything at once. Pick the scenes you’re actively still editing, rename and log those, and let the rest sit in an “unsorted” folder you’re allowed to ignore. Does this replace tracking model versions and seeds for reproducibility? It complements it. The naming convention and log described here are about finding and understanding your existing clips. Reproducing a clip after a model update silently changes its behavior is a related but separate problem worth its own system. How much time does this actually save? Enough that it stops being optional past a few dozen clips. The Lost Garden corridor rebuild that opened this piece took three full passes partly because there was no reliable record of what earlier attempts had already tried.
View original source — Hacker Noon ↗



