Why most file names stop working after weeks
Bad file names do not feel dangerous until the wrong clip gets approved. A director comments on scene04_final.mp4, an editor uploads scene04_final_new.mp4, and the archive keeps scene04_final_revised_real.mp4. Two of those files are test crops, one has the right acting beat, and none of the names say which prompt or selected take produced them.
AI anime production multiplies this problem because each shot can have prompt drafts, reference sets, generated takes, selected takes, cleaned finals, voice passes, platform crops, cover frames, and archive copies. A name like girl_rooftop_good.mp4 may work for a solo experiment, but it collapses when the project has episodes, languages, aspect ratios, review status, and revision history.
A naming convention should make a file findable without forcing the filename to carry every piece of context. That context already lives inside ArcLoop: the project, the episode (EP1, EP2...), and the shot card in the storyboard. Filenames for anything you keep outside ArcLoop — local exports, reference images before they're bound to an asset — only need enough structure to identify the project, episode, shot, and version. Use character profile fields to keep naming tied to production flow, and ArcLoop Worlds when the same characters and locations need long-term continuity.
Rules for file names that survive edits
Names should sort in production order. Put the broadest unit first: project, episode or sequence, shot, asset type, variant, version, and status. When files sort naturally, reviewers can scan a folder without opening everything.
Use stable IDs, not scene descriptions, for the core name. A label like Shot 2 survives script edits better than balcony confession. Descriptive words can appear as a short variant label, but the ID should remain the anchor.
Keep status vocabulary small. Use a limited set such as draft, select, review, approved, final, rejected, and archive. If every teammate invents a status word, naming stops being a convention.
Move long explanations out of the filename. It shouldn't need to include the prompt text, camera notes, or every character name — that detail already lives in the shot card and, for identity, in the character asset it references with @.
Protect approved work from overwrites. Never reuse the same name for a changed file. Increment the version or change the status. This is basic, but it prevents the quiet disaster of replacing the only approved take with a later test.
How to build a naming pattern: from fields to first export
Start by choosing the units your project actually uses. A short standalone clip may only need project, shot, asset type, version, and status. An episodic series may need project, season, episode, sequence, shot, take, variant, version, and status. Do not add fields that nobody will search.
Define a simple pattern. One practical pattern is PROJECT_EPISODE_SHOT_TYPE_VARIANT_v##_STATUS.ext. For example, GARDEN_E01_SH012_clip_master_v03_approved.mp4. Keep all letters in one case and avoid spaces so exports behave cleanly across tools.
Create allowed values for type and variant. Type might be prompt, ref, take, clip, cover, voice, caption, manifest, or note. Variant might be master, vertical, square, clean, subbed, cropA, or paletteB. Allowed values prevent folder drift.
Write the version rule. Drafts and revisions should increment the version whenever the file content changes. Status changes can either create a copied status file or update the manifest status, depending on the workflow. The important rule: content changes must not overwrite approved files.
Tie filenames back to the project instead of trying to replace it. A short handle with the project, episode, and shot is enough — the shot card inside ArcLoop, and the character or scene assets it references with @, are still the source of truth.
Run a naming review before batch export. Check for duplicate IDs, missing versions, mixed status words, files without source shots, and platform variants that look like masters. This takes minutes and saves hours.
Document the rename path for messy legacy folders. If a file was already shared with an editor or client, keep the old name in the manifest as an alias until the new package is accepted. Renaming should improve traceability, not break every comment thread that points to yesterday's file.
What goes in the filename, what stays in ArcLoop
The filename can stay small because ArcLoop already holds the real context — the character and scene assets, the Story Outline, and each shot inside its episode storyboard. That means a local file called NIGHT_E02_SH006_clip_vertical_v02.mp4 can stay short and readable, because the detailed story and identity context sits in the linked project, not in the name.
For teams, the practical boundary is this: the filename carries identity, ArcLoop carries meaning. Put project, episode, shot, type, variant, and version in the name. Put the story itself in the Story Outline, and the actual identity references in the shot description via @.
Once the team agrees on a naming rule for local files, write it down before the first export — it only needs to apply outside ArcLoop, since inside the project every shot already has a stable place in its episode's storyboard. No one should have to rename a season by hand after the fact.
The same discipline helps when you're comparing attempts. On the Canvas, you can branch a shot, try a different take, and go back to an earlier version without losing track of which is which — a stable local file name for anything you export just keeps that history straight outside the project too.
Here is how this boundary works in practice inside ArcLoop before you ever name an export file.
Open your IP Project and go to My Assets. Create a Character asset for each recurring person — for Copper Harbor, that is Captain Elian Ro. Upload the reference image to Library, then Bind it to the asset as Main image. Add a second angle or costume as a Reference image if you have one.
Enter Episode 1 and click Generate Shots. ArcLoop drafts a set of shot cards from your Story Outline. In each shot card, type @Captain Elian Ro to pull the captain's identity in — you do not need to re-describe his face or coat. Write only what is new in that specific shot: the action, the camera angle, the light.
Generate the image for Shot 1 first to confirm framing and character design before committing to video. Once the image looks right, generate the video. Use the AI Chat Panel to move through multiple shots at once: "Generate videos for Shots 1, 2, and 3." When you are happy with the takes, bring them into Edit to arrange and trim on the timeline.
Only at the Export step does a local filename matter. By then the shot card — with its @ reference, its description, and its position in the episode storyboard — already holds every meaningful detail. The filename just needs to be a short, sortable handle.
Example 1: Naming convention for Copper Harbor
Write a file naming convention for local exports from the Copper Harbor project.
Production shape: 3 short episodes, one recurring captain character asset (@Captain Elian Ro), 8 to 12 shots per episode. Export types include master clips, vertical social cuts, cover images, and caption files.
Naming pattern: COPPER_E##_SH###_TYPE_VARIANT_v##_STATUS.ext
Allowed TYPE values: clip, cover, caption, ref.
Allowed VARIANT values: master, vertical, square, subbed.
Allowed STATUS values: draft, review, final.
Version rule: increment v## whenever file content changes. Never overwrite a file already shared with the team.
Context rule: story detail, shot descriptions, and @asset references all stay inside the ArcLoop project. The filename is a short handle, not a substitute for the shot card.
This prompt gives the team a rule small enough to follow and strict enough to catch the usual mistakes.
Example 2: Naming a take selection set
Prepare filenames for a take-selection set in Copper Harbor episode 2, shot 7.
Shot context: Captain Elian Ro holds a cracked compass on the pier while fog clears behind a copper lighthouse.
Files to name: three exported takes from Canvas branches, and one that got rejected for an off-model compass.
Use the project naming pattern and keep descriptions out of the filename.
Output examples:
COPPER_E02_SH007_take_v01.mp4
COPPER_E02_SH007_take_v02_select.mp4
COPPER_E02_SH007_take_v03_rejected.mp4
Note: the reason for rejecting v03 belongs in the shot description or a note kept with the project, not in the filename.
The shot description is still useful, but it belongs in the shot card. The file name stays operational.
Example 3: Renaming a messy export folder
Audit and rename a messy Copper Harbor export folder using the approved convention.
Current problem: files are named final.mp4, final2.mp4, good_vertical.mp4, cover_new.png, and captions_real.srt.
Known mapping: final.mp4 is E01 SH010 master v02; final2.mp4 is E01 SH010 master v03; good_vertical.mp4 is E01 SH010 vertical v01; cover_new.png is E01 cover v02; captions_real.srt is E01 captions v01.
Rename plan: produce the new filenames, keep the original files until the renamed copies are checked, and write down the old-name-to-new-name mapping somewhere the team can find it.
Do not change creative content, prompts, captions, or approval notes.
Flag any file that lacks enough mapping information instead of guessing.
This is the correct use of naming cleanup: map known facts, avoid creative changes, and refuse to guess missing provenance.
Ways file naming falls apart
The most common mistake is using final too early. A file can be creatively selected, delivery-reviewed, platform-cropped, or archived. Reserve final for the deliverable that has passed the required checks.
Another mistake is packing the whole story into the name. sad-captain-foggy-pier-compass-closeup-best-v2 may feel helpful, but it breaks sorting and still omits approval status. Put story words in the shot card.
Teams also mix naming conventions across people. One creator writes E1S4, another writes ep01-shot004, and the editor writes scene4. Pick one pattern before generation starts.
A fourth mistake is letting platform variants look like masters. A vertical crop, square crop, subtitled version, and clean master are different deliverables. The variant field should make that obvious.
FAQ
What fields should every AI anime filename include?
Use project, episode or sequence when needed, shot ID, asset type, variant, version, and status. Smaller projects can drop fields they do not use, but every changed file should have a version.
Should character names go in the filename?
Usually no. The character's identity already lives on its asset in My Assets and gets pulled into the shot with @ — the filename doesn't need to repeat it. Use the episode and shot number instead (like E02_SH007); that sorts better and survives script rewrites better than a description would.
How do I handle rejected takes?
Keep one rejected file when it explains a useful failure, name it with rejected, and put the reason in metadata. Do not keep dozens of repeated rejects with vague names.
How do I keep filenames short without losing context?
The shot description, the @ asset references, and the character assets themselves all stay linked to the shot inside the project. The filename only needs to be a short handle — project, episode, shot, version.
When should I create the naming convention?
Before the first real batch. Naming after production is cleanup; naming before production is prevention. Add the pattern to the project setup so every prompt, take, clip, caption, and cover follows the same rule.
What if older files already use messy names?
Map old names to new names somewhere the whole team can see before changing anything. Rename only files with a known source shot. Leave uncertain files flagged for review rather than inventing provenance.
