Shot Naming Conventions for AI Vertical Drama Production

How to Build a Shot Naming Convention That Survives Handover Between Generation Operators

An operator goes on holiday in week six. Somebody else picks up episode thirty one. Two hours later the question arrives in the channel: which of these four files is the approved version of the rooftop shot, and why are three of them called final. Nobody can answer without opening all four, comparing them against the episode cut, and asking the operator who is not available. The episode ships a day late, and it ships with the wrong take.

This is a naming problem, not a talent problem. On a seventy episode vertical drama the shot count runs into the high hundreds, sometimes past a thousand once retakes are counted. Every one of those files carries a name, and that name is either doing work or it is not. When it is not, the knowledge about which file matters lives in one person's head, and it leaves the production when they do.

A naming convention is the cheapest continuity system available. It costs an afternoon to design and nothing to operate. What follows is the structure that holds up under handover, the ordering that makes filesystems useful rather than hostile, and the specific failure modes that break conventions on long form productions.

1. What the Convention Is Actually For

Naming conventions get designed for the wrong reader. Most are designed to be descriptive, so an operator can look at a filename and remember what the shot contains. That is a weak requirement. The person who generated the shot already knows what it contains.

Design for the person who has never seen the shot and needs to make a decision about it in under a minute. Three decisions, specifically. Which episode and scene does this belong to. Is this the approved version. What produced it, if I need to make another one that matches.

A name that answers those three questions supports handover. A name that describes the visual content does not, because the visual content is already visible in the file. Descriptive naming feels helpful and delivers almost nothing operationally, which is why so many productions have thoughtful, readable filenames and still cannot answer basic questions in week six.

The second reader is the machine. Names are sorted, filtered, batch processed and matched against edit decision lists. A convention that a script can parse is worth several times one that only a human can read.

2. The Six Fields Every Shot Name Needs

Six fields cover a vertical drama pipeline. Fewer leaves ambiguity, more introduces fields that operators stop filling in correctly by week three.

Series code. Two to four characters, fixed for the life of the production. This matters the moment a studio runs two series at once and assets end up in a shared review folder.

Episode number. Zero padded to three digits. Episode nine is 009, not 9. Padding is not cosmetic, it is what makes sorting work, and a production that skips it will spend the rest of its life looking at episode 1, episode 10, episode 100, episode 11.

Scene number. Zero padded to three digits, matched to the script scene numbering and never renumbered after lock. If scenes are added after lock, use a suffix rather than renumbering: 042A rather than shifting everything downstream. Renumbering after lock is the single most destructive thing that can happen to a naming system, because it invalidates every reference in every document that points at the old numbers.

Shot number. Zero padded to three digits within the scene, in intended cut order at the time of breakdown. It will not match the final cut order exactly. That is fine. The shot number is an identifier, not a position.

Version. Zero padded to two digits, incrementing on every generation attempt of that shot.

Status marker. A short controlled token indicating where the file sits in the pipeline. Keep the vocabulary small and closed: wip, rev, apr, fin. Work in progress, in review, approved, final delivered. Four tokens. Not seven, and never free text.

A shot name assembled from those six fields reads as something like AXR_E031_S014_SH003_v07_apr. Machine parseable, sorts correctly, and answers all three handover questions without opening anything.

3. Ordering the Fields So the Filesystem Sorts Correctly

Field order is not stylistic. It determines what a directory listing looks like, and a directory listing is the interface most operators actually use.

Order from largest scope to smallest, with the mutable fields last. Series, episode, scene, shot, version, status. Sorted alphabetically, which is what every filesystem does by default, this groups everything from an episode together, then everything from a scene, then all versions of a single shot in ascending order with the newest at the bottom of its group.

Putting version or status early breaks this completely. A convention that leads with status groups every approved shot in the production together and scatters the versions of a single shot across the entire listing. It looks organised and it is unusable.

Use a single consistent separator. Underscores between fields, hyphens never, or the reverse, but pick one and enforce it. Mixed separators defeat parsing, and parsing is half the value. Avoid spaces entirely. Avoid characters that require escaping in shell commands or that behave unpredictably across operating systems, which rules out most punctuation beyond the underscore and the hyphen. Productions that move files between Windows, macOS and Linux environments discover this the expensive way.

Keep the whole name under about sixty characters. Long names get truncated in review tools, in file browsers and in delivery portals, and the field that gets truncated is always the one at the end, which is why status sits last and matters least to a machine.

4. Versioning and Retakes Are Not the Same Thing

Most conventions collapse these two ideas and then cannot answer the question that matters most at review: was this shot regenerated because the first attempt failed technically, or because the creative direction changed.

Version increments on every generation attempt. It is a simple counter and it never resets. Version 07 is the seventh time anyone generated this shot, regardless of why.

Retake reason is separate metadata, not part of the filename. Keep it in a retake log keyed to the shot identifier and the version number. Three or four categories are enough: technical defect, continuity break, direction change, client note. This is the data that tells a production which parts of the pipeline are underperforming, and it is invisible if it lives inside filenames or inside nobody's head.

The distinction pays off twice. During production, a shot at version 12 with eleven technical defect entries is a pipeline problem, while a shot at version 12 with eight direction change entries is a briefing problem, and those get fixed by different people. After delivery, the retake log is the fastest available map of where the standard was hardest to hit, which is what informs the next series.

Never overwrite a version. Never use words like final, latest or new inside a filename. They are the reason there are four files called final in the rooftop folder. The status token carries approval state, the version number carries sequence, and neither of them ever describes itself as final in prose.

5. Name the Inputs, Not Just the Outputs

Shot names solve half the handover problem. The other half is the assets that produced the shot, and productions that name outputs carefully and inputs casually still cannot reproduce a shot six months later.

Character references need their own convention, keyed to the character and versioned independently: series code, character code, reference type, version. Style references likewise. Where trained character models are in use, the model identifier belongs in the same scheme so that a shot can be traced to the exact model version that produced it.

Then link them. Every generated shot needs a sidecar record, a small structured file carrying the shot identifier, the reference asset identifiers and versions, the model or tool version, the seed where one applies, and the prompt or generation configuration. This is the record that makes a shot reproducible after the operator who made it has moved on, and it is the difference between a production that can deliver a matching pickup shot in month nine and one that has to rebuild the look from scratch.

Broadcast and streaming delivery has had structured identifier practice for decades, and the underlying discipline transfers directly. The standards work published by SMPTE on media identifiers and metadata is the reference point if a production wants its internal scheme to align with something durable rather than something invented in week one.

6. Where Conventions Break

Four failure modes account for nearly all of it.

Scene renumbering after lock, covered above. Guard it with a rule rather than a request: scene numbers are frozen at breakdown, additions take letter suffixes, deletions leave a gap.

Manual entry. Every field an operator types by hand is a field that will eventually be typed wrong. Generate names from a template wherever the pipeline allows it, even if the template is a spreadsheet formula or a six line script. A production that renames files by hand at volume will accumulate a steady error rate no amount of care removes.

Vocabulary drift. Status tokens expand. Someone adds pending, then hold, then apr2. Within a month the closed vocabulary is open and filtering stops working. Publish the token list, put it in the pipeline documentation, and treat additions as a decision rather than a convenience.

Parallel schemes. The editor names things one way, the generation team another, the client another again. Names diverge at every handoff and someone spends their week reconciling. Decide the scheme once, before the first shot, and make it the scheme in the delivery specification as well as the working folders. If a client requires different delivery names, generate them at delivery from the internal scheme rather than working in the client scheme throughout.

7. The Twenty Minute Handover Test

Test the convention before committing to it. The test is simple and it takes twenty minutes.

Take someone who has not worked on the series. Give them access to the shot folders for one episode, the character reference folder and the retake log. Nothing else. No briefing, no walkthrough.

Ask them four questions. Which version of scene fourteen shot three is approved. How many times was that shot regenerated and why. Which character reference version was used to produce it. If you had to generate a matching shot tomorrow, what would you need.

A convention that supports handover produces four correct answers in under twenty minutes with no help. A convention that does not will fail on the third question, almost always, because input naming is the part productions skip.

Run the test again at episode twenty. Conventions decay, and the decay is invisible from inside the production.

8. Rolling It Out Mid Production Without Renaming Everything

Most productions discover they need a convention around episode fifteen, after the problem has already cost them something. Renaming the existing library is rarely the right move. It breaks every existing reference, consumes days, and introduces errors into material that has already been approved.

Draw a line instead. Apply the new convention from the next episode block forward. Freeze the legacy material under its existing names and write a single mapping file that translates old identifiers to new ones for anything still in active use. Most legacy shots are already delivered and will never be touched again, so the mapping only needs to cover what remains live.

Backfill the sidecar records for approved shots only, and only for shots likely to need matching pickups or sequel reuse. That is usually hero shots, establishing shots and any shot featuring a principal character in a costume that recurs. Everything else can stay as it is.

Announce the cut over date, publish the field definitions and the token vocabulary on one page, and generate the names from a template from day one of the new block. The convention that gets adopted is the one that is easier to follow than to ignore.

Axis AI Studios Perspective

Axis AI Studios is an AI native vertical drama production studio based in the Netherlands. We build and operate production pipelines for commissioned series, and naming is one of the first things we set before generation begins.

Our position is that reproducibility is a deliverable, not a courtesy. A series that cannot produce a matching pickup shot nine months after delivery has lost real commercial value, because sequels, spin offs and localisation all depend on the ability to return to the look. That capability lives in the naming scheme and the sidecar records, not in the finished files, and it is built during production or not at all.

We also treat handover as a design constraint rather than a risk to be managed. Operators change across a long series. Coordinators change. A pipeline that only works while a specific person is available is not a pipeline. We would rather spend an afternoon on field definitions in week one than a week reconstructing provenance in month six.

We work with platforms, brands, IP holders and media companies commissioning original vertical drama. If you are standing up a production pipeline and want the naming scheme and asset tracking structure documented before generation starts, write to business@axisaistudios.com.

FAQ

Should the naming convention include a description of what the shot contains?

No. Descriptive content in a filename adds length, invites free text and inconsistency, and answers a question the file itself already answers when opened. Content description belongs in the shot list and the sidecar record, where it can be searched, filtered and corrected without renaming anything. Keep the filename to structured identifiers that a script can parse and a stranger can act on.

How do we handle shots that appear in more than one episode, such as recaps or flashbacks?

Give the shot one canonical identifier from the episode where it originates, and reference that identifier from the reusing episode rather than duplicating and renaming the file. Track the reuse in the shot list. Duplicating with a new episode number creates two files that can drift apart if one gets a retake, and productions usually discover the drift during final conform, which is the worst moment to discover it.

Does the convention need to match what the platform requires at delivery?

Not during production. Platform delivery specifications vary and often use their own identifier scheme, so working in the client scheme throughout means the internal pipeline inherits an external constraint it does not need. Keep an internal convention designed for production, then generate delivery names from it as a mapping step at the delivery gate. Build the mapping once and reuse it, and confirm the platform specification early since ingest requirements are documented in advance by most operators, including the specifications published through the Netflix Partner Help Center.

Further Reading

For the wider tracking system that a naming convention plugs into across a long series, how to build a vertical drama continuity bible covers tracking seventy episodes without drift when production runs out of order.

For the review process that consumes these names in practice, how to run quality control on 900 generated shots without reviewing every one sets out a sampling and escalation framework that depends on shots being identifiable at a glance.

For what happens to all of this after delivery, how to archive an AI vertical drama production for sequel use covers what to save, how to store it and what you will actually need eighteen months later.