Asset operations

Directory, naming, and version rules for a short-drama library

Clear names and version relationships reduce duplicate processing, missing episodes, and wrong-language delivery.

Key conclusions

• Name series, episode, language, channel, version, and status consistently.
• Keep source and derived outputs distinguishable.
• Use a manifest or workspace state instead of relying on filenames alone.

Directory structure is not a substitute for a production model, but a chaotic directory makes every model harder to use. The name should tell a human which series and episode a file belongs to, while a manifest or workspace record carries the exact source, locale, task, version, and rights context.

Separate the original handoff from working and approved outputs. Do not overwrite a source because a localized version looks better. When a correction occurs, create a new version or record the change so reviewers know which package is current.

The rule should work for web downloads, API outputs, review files, and channel packages. Test it on a batch with multiple languages and a rework before calling it reliable.

Use filenames for stable identity, not the whole project history

A filename should help identify series, episode, language, asset type, and version. It should not carry every review message, rights exception, or processing state in an ever-growing string.

• Keep series, episode, locale, asset type, and version predictable.
• Use a manifest or system fields for status, owner, rights, and review.
• Never overwrite an approved source or silently reuse final as a version label.

Separate source, work, and delivery directories

A practical structure preserves the original handoff, keeps shared approved assets distinct from language workspaces, and places only accepted outputs in delivery. This makes it harder for a working subtitle or unreviewed export to become the release master by accident.

Make the naming rule testable

A naming rule is useful when another person can identify the file without guessing and a script can detect missing or duplicate units. Test a representative batch, then document how replacement, cancellation, and archive states are handled.

1. Define stable fields and allowed values.
2. Create a manifest for the series.
3. Validate names, count, version, and language.
4. Mark replacements without deleting lineage.
5. Archive with rights and review notes intact.

Frequently asked questions

Should status be encoded in the filename?

Only stable, operationally useful fields belong there. Detailed review and delivery state should remain in a manifest or production system.

Can approved files be overwritten to keep directories tidy?

No. Preserve the relationship between the previous and replacement versions.