How to Version a Vertical Drama Delivery Master So a Platform Reingest Does Not Start From Scratch

Episode thirty one. A subtitle typo in the second line of dialogue. Seventy episodes already ingested and live. The platform asks for a corrected file, and the production team cannot say with certainty which master the platform holds, which edit it came from, or whether the sound mix on that episode was updated after delivery. So the safest option becomes the most expensive one: resend everything, and ask the platform to ingest the series again from the top.

That outcome is avoidable. It is not a technical failure of the platform or the codec. It is a versioning failure, and it starts long before delivery, at the moment the team decides what a master is and how one master differs from the next. This piece sets out a working system for versioning a vertical drama delivery master so that any correction, at any point after delivery, travels as a small, traceable patch. The system applies to a single series or a full slate, and it costs very little to set up at the start compared with what it saves at the end.

1. Why a Small Fix Turns Into a Full Redelivery

A platform reingest goes wrong for a predictable reason. The platform holds one set of files, the production team holds another, and nobody can prove the two sets match. When a fix is requested, the team cannot isolate the single file that needs replacing, because it cannot confirm what sits on either side of it. Uncertainty spreads outward from one episode to the whole series.

Platforms respond to that uncertainty rationally. An ingest team that receives a single replacement file with no context has to decide whether to trust it, and trust is cheaper when the delivery is complete and self consistent. So the request for one corrected subtitle becomes a request for the full package. The production team then spends days on exports, checks and uploads that add nothing to the series. The fix itself takes minutes. Everything around it takes the time.

2. Define What Counts as the Master

Before any version number exists, the team needs a written definition of the master. For a vertical drama episode, the master is rarely one file. It is a picture file, a set of audio stems and a final mix, one or more subtitle or caption files, on screen text layers where they exist, artwork such as thumbnails and episode cards, and a metadata record covering titles, durations and episode order. Each of these components can change independently, and each one has to be named as part of the master or it will drift outside the system.

The definition should also say what is not part of the master. Working files, generation outputs, project files from the edit and reference material belong to production, not to delivery. Keeping them out of the master keeps the delivery package small and keeps the version history clean. A useful test is simple. If the platform ingests it, it belongs to the master. If only the production team opens it, it belongs to the archive.

3. Use a Version Identifier That Carries Meaning

The most common versioning scheme in production is no scheme at all. Files arrive named final, final two, final approved and final fixed, and within a month nobody remembers which came first. A version identifier should carry enough meaning to be read without opening a spreadsheet. A structure borrowed from software versioning works well here, with a major number, a minor number and a patch number for each episode master.

The major number changes when the edit changes, meaning a cut is added, removed or reordered. The minor number changes when the sound mix or the grade changes without touching the edit. The patch number changes for text level corrections, such as a subtitle line, a caption timing or a metadata field. So episode thirty one at version two point one point three tells an ingest team, at a glance, that the edit has changed once since first delivery, the mix once, and the text three times. That single string replaces a conversation.

The identifier should sit in the file name and in the metadata record, and the two must always agree. Where they disagree, the metadata record is treated as the source of truth, and the file is renamed to match. Consistency matters more than the exact format chosen. A team that uses a slightly different scheme but applies it to every file, every time, will reingest cleanly.

4. Write a Change Manifest for Every Version

A version number tells the platform that something changed. A change manifest tells it what. For every new version of an episode master, the team writes a short record listing the components affected, the reason for the change, the person who approved it and the date it was exported. The manifest is plain text, kept alongside the delivery, and it travels with every patch.

The manifest is what allows an ingest team to replace one file with confidence. If the record says that only the English subtitle file changed on episode thirty one, and that picture, stems and artwork are untouched, the platform can swap a single file and leave the rest of the episode as it is. Without the manifest, the platform has to assume that anything might have changed. Over a long series, the manifests also become a readable history of the delivery, which is useful for audits, sequel planning and any later dispute about what was approved and when.

5. Fingerprint Every File With a Checksum

Names can be wrong. Dates can be wrong. A checksum cannot be wrong in the same way. A checksum is a short string calculated from the contents of a file, and any change to the file, however small, produces a different string. Recording a checksum for every component of every master version gives both sides of the delivery a reliable way to confirm that the file they hold is the file they think they hold.

In practice, the checksum list sits inside the change manifest, one line per file. When a patch is delivered, the platform can calculate checksums for the files it currently holds, compare them against the list for the previous version, and confirm that only the expected files differ. This removes the uncertainty that drives full redeliveries. It also catches the quieter problems, such as a file that was corrupted in transfer or an export that was overwritten by mistake on a shared drive. The cost is a few seconds per file. The protection lasts for the life of the series.

6. Version Picture, Sound and Text Separately

The single biggest gain in this system comes from treating the components of a master as separately versioned items under one episode identifier. Picture, final mix, stems, subtitle files per language, on screen text layers and artwork each carry their own internal revision count, recorded in the manifest, while the episode version summarises the state of the whole. A subtitle correction in one language then touches one file and one line of the manifest, and nothing else.

This only works if the components were built as separable items in the first place. Burned in subtitles, text baked into the picture and a mix delivered without stems all tie unrelated changes together. A spelling fix in on screen text becomes a new picture export, which becomes a new picture checksum, which forces the platform to replace the heaviest file in the episode. The separation decision is therefore a production decision as much as a delivery one, and it is far easier to make before the first block of episodes than to retrofit after episode seventy.

What separation looks like in the delivery folder

Each episode folder holds one subfolder per component type, and each file name carries the series code, the episode number, the component, the language where relevant and the episode version. The manifest sits at the top of the episode folder. A reader who has never seen the series should be able to open the folder and understand what is current without asking anyone.

7. Agree the Patch Path With the Platform Before First Delivery

A versioning system that only one side understands will still end in a full redelivery. Before the first episode is delivered, the production team and the platform ingest team should agree three things in writing. First, which components the platform will accept as individual replacements. Second, what the platform needs to see in a manifest before it accepts a patch. Third, how a patch is signalled, whether through a portal, a shared folder or a named person at the ingest team.

Some platforms will accept a single replacement subtitle file with a manifest. Others will only accept a full episode package, even for a text change. Knowing this in advance changes how the team builds the master. If the platform only accepts full episodes, the goal shifts to making a full episode redelivery fast and clean rather than avoiding it. Either way, the conversation belongs before delivery, not in the middle of a correction request, when the series is already live and the pressure is highest.

8. Keep Superseded Versions, Not Just the Latest

The final rule is the one most often broken under pressure. When a new version of a master is exported, the previous version is kept, unchanged, in a superseded area of the archive. It is not overwritten, renamed or deleted. The platform may hold an older version for weeks after a patch is sent, a regional partner may have ingested a version that predates a correction, and a later dispute may hinge on exactly what was delivered on a specific date.

Keeping superseded versions also protects the team from its own mistakes. A patch that introduces a new error can be rolled back to the last known good version immediately, with checksums to prove it. Storage for superseded masters is a small cost against the value of being able to answer, at any point, the question of what the platform received and when. Over a slate of several series, that answer becomes one of the most useful things a production team can offer.

9. Give the Delivery Record a Single Owner

Every part of this system depends on one habit: the delivery record is kept current by one named person. On most vertical drama teams, that person is the production coordinator or a dedicated delivery lead. Editors, sound specialists and operators can all produce new versions of components, but none of them updates the delivery record directly. They hand the new file and a one line reason to the owner, who assigns the version, writes the manifest entry, calculates the checksum and files the superseded version.

This sounds like extra process. In practice it removes process, because it ends the situation where three people each believe someone else has logged a change. A single owner also gives the platform one reliable point of reference for every question about what was delivered. When a correction request arrives, the owner can answer within minutes which version the platform holds, which components the fix touches and what the patch will contain. That quick, confident answer is often what persuades an ingest team to accept a patch instead of asking for the whole series again.

A short weekly reconciliation

Once a week during delivery, and once a month after the series is live, the owner compares the delivery record against the files in the delivery area and against any confirmation the platform has sent. Mismatches are rare when the system is followed, but when one appears it is far cheaper to resolve in a quiet week than in the middle of a correction request. The reconciliation takes less than an hour for a full series. It is the step that keeps the record trustworthy over the life of the licence.

Axis AI Studios Perspective

Delivery is where a series stops being a production and starts being an asset on a platform shelf. The way a master is versioned decides how easily that asset can be maintained once it is there. At Axis AI Studios, delivery masters are treated as structured packages from the first block of episodes, with picture, stems, mix, subtitle files and on screen text built as separate components, so that a correction stays the size of the problem rather than the size of the series.

The same discipline runs through the rest of the pipeline. Every shot traces back to its source, every generation session is recorded, and every episode master carries a version identifier, a manifest and a checksum list before it leaves the studio. None of this is visible on screen. It is visible when a platform asks for a fix and receives one clean file with a clear record of what changed. For platforms and commissioning teams planning a series where long term maintenance matters as much as the first delivery, the delivery structure is worth discussing at the brief stage. Send the delivery specification and the platform ingest requirements to business@axisaistudios.com and the conversation can start from the master outward.

FAQ

Does every platform accept single file patches for a vertical drama episode?

No. Acceptance varies by platform and sometimes by region or ingest partner. Some ingest teams will replace an individual subtitle or artwork file when a manifest and checksum list accompany it. Others require a complete episode package for any change, however small. The patch path should be agreed in writing before first delivery, so the master can be built around what the platform will actually accept.

What is the minimum versioning system a small production team should use?

A clear definition of the master, a version identifier in every file name, a short change manifest for every new version and a checksum for every delivered file. That combination fits in a single folder template and a short text file per episode. It is enough to turn most correction requests into small patches, and it scales from one series to a full slate without changes.

How long should superseded masters be kept after a series is delivered?

For at least the full licensing term of the series, and ideally for as long as any version could still be in circulation with a platform or regional partner. Superseded masters are the evidence of what was delivered and when. They also allow a fast rollback if a patch introduces a new error. Storage cost is modest compared with the value of a complete delivery history.

Further Reading

For teams that want the same traceability inside production as they have at delivery, the guide to building a shot level provenance record covers how every frame in an episode can be traced back to the prompt and session that produced it.

For a wider view of what to keep once a series wraps, the guide to archiving a vertical drama production for sequel use covers what to save, how to store it and what a sequel team will need later.

For the generation side of reproducibility, the piece on managing generation sessions and seeds across a long series covers how to record sessions so any shot can be regenerated on request.