How to Version Control Character References Across a 70 Episode Generation Pipeline

1. Episode 41 and the Face That Changed

The delivery note comes back from review and it is specific. The lead looks different from episode thirty eight onward. Not dramatically. The jawline is slightly narrower, the hairline sits a few millimetres higher, and in wide shots it barely registers. In close ups, which is most of vertical drama, it registers immediately.

Someone goes looking for the cause and finds it in about forty minutes. An operator updated the character reference pack in week five to fix a wardrobe problem, saved it over the existing folder, and carried on. Everything generated after that used the new pack. Nobody was told, because the change looked like a small correction rather than a version event. The old pack no longer exists. Episodes thirty eight through forty one now have to be regenerated against a reference nobody can reconstruct exactly, or the whole run has to move forward on the new face and the earlier episodes get reviewed again to see whether the discontinuity is survivable.

This is not an unusual failure. It is close to the default outcome on any long run where reference assets live in shared folders and are edited in place. The problem is not that the operator did something careless. The problem is that the pipeline offered no way to change a reference correctly. Version control for reference assets is the mechanism that makes the correct action available and the incorrect one difficult.

2. What Actually Counts as a Reference Asset

Before anything can be versioned, the set has to be defined, and productions routinely define it too narrowly. Reference means more than a folder of character stills.

The image set is the obvious component: the front, three quarter and profile views, the expression range, the full body shots that establish proportion. Alongside it sits the wardrobe set, which is often organised separately because a character carries several looks across a series and each one needs its own coverage. Then the trained assets, where a production has trained a model on a character, which carries its own training data, its own configuration and its own output checkpoint. Then the textual description that accompanies the images in every prompt, which is a reference asset even though it is prose. Then the generation parameters that were locked for that character: the seed values that produce consistent output, the sampler settings, the strength values at which the reference is applied.

All five drift independently and all five change the face. A production that versions only the image folder will still get episode forty one, because the description was edited or the strength value was nudged and neither of those was covered. The unit of versioning is the reference pack as a whole, containing every component, moving together.

The practical consequence is that a reference pack has to be a single named, dated, complete thing rather than a set of files distributed across a project structure. If reproducing a shot requires assembling components from four locations, the pack will eventually be assembled wrongly.

3. A Numbering Scheme That Survives Handover

Reference packs need a version number that communicates something to the person reading it, which means the increment has to carry meaning. The convention borrowed from software works well here, and the logic behind semantic versioning transfers almost directly: a major increment signals a change that breaks compatibility with what came before, a minor increment signals an addition that does not, and a patch increment signals a correction that changes nothing about how the asset behaves.

Applied to a character reference pack, a major increment means the face has changed. New training run, substantially different image set, altered proportion or age. Anything generated against the previous major version will not cut against anything generated after it. This is the version change that requires a production decision rather than an operator decision.

A minor increment means something has been added without altering the established look. A new wardrobe set for episodes forty onward. An additional expression range for a scene the original coverage did not support. A new angle added because the original set lacked a low view. Shots generated against the previous minor version remain valid and can sit next to new ones.

A patch increment means a correction with no visual consequence. A mislabelled file renamed. A duplicate removed. A typo fixed in the description. Nothing regenerates.

The identifier travels with the character, so a pack reads as the character name and the version together. LEAD_MARA_v2.1.0 tells an operator that this is the second face, the first wardrobe addition on that face, and no corrections since. That is legible at handover in a way that a dated folder name is not, and it makes the crucial question, whether this shot and that shot share a major version, answerable at a glance.

4. Immutability Is the Rule That Makes the Rest Work

Everything above collapses without one rule enforced without exception: a published reference version is never edited. Not corrected, not tidied, not updated in place. Changes create a new version. The old version stays exactly where it was, exactly as it was, for the life of the production and beyond.

This is the rule that people find uncomfortable, because it produces what looks like clutter. Fourteen versions of a character pack sitting in storage when only the latest is in active use. The discomfort is misplaced. Those old versions are the only thing that makes an earlier episode reproducible, and reproducibility is the entire point. A production that needs to regenerate three shots from episode twelve in month five needs the pack that episode twelve was made with, not the pack as it stands now.

Enforcing immutability is mostly a permissions question. The active working area is where a new version gets assembled and tested. The published reference store is write once, and operators generating shots read from it rather than working inside it. Once a version is published into that store, the tooling should refuse to overwrite it. Where the storage system cannot enforce that, the fallback is a naming convention that makes overwriting obviously wrong and a periodic check that no published version has a modification date later than its publication date.

The cultural half of the rule matters as much as the technical half. Operators need to know that creating a new version is cheap and expected, not a bureaucratic event to be avoided. A pipeline where cutting v2.3.0 requires an approval meeting is a pipeline where somebody quietly edits v2.2.0 instead.

5. Storage and the Large File Problem

Reference packs are heavy. Image sets run to hundreds of files, trained model checkpoints are large binaries, and a production carrying eight characters through fourteen versions each is holding a substantial volume that has to remain retrievable for years rather than months.

Ordinary version control systems handle text well and binaries badly, which is why productions that try to put reference packs into a standard repository end up with something slow and unusable. The established answer is to keep the pointer in version control and the payload elsewhere, which is what Git LFS was built for: the repository holds a small reference to each large file while the file itself lives in dedicated storage. Productions that are not already working in a repository can achieve the same separation with a manifest file listing every component of a pack, its location, and its checksum, held in a lightweight versioned document while the assets sit in object storage.

Either way, the requirement is the same. The manifest is small, readable, and versioned. The assets are large, immutable, and addressed by the manifest. Checksums matter here more than they seem to, because silent corruption in a large image set is otherwise invisible until a generation looks subtly wrong for reasons nobody can trace.

Retention is worth deciding at the start rather than at the point of a storage bill. Major versions and any version used to generate delivered footage stay indefinitely. Intermediate versions that were tested and never used to generate anything delivered can be pruned once the series is complete. That distinction is only knowable if generations record their reference version, which is the next piece.

6. Binding a Version to a Shot

A version control scheme with no link to output is a filing system. The link is made by recording, for every generated shot, the exact reference version used. That record belongs in the same place as the shot metadata, alongside the prompt version, the tool and model version, and the seed.

Captured automatically at generation time, this record answers the questions that otherwise take forty minutes and a guess. Which reference version produced this shot. Which shots in this episode share a reference version. Which episodes will need regeneration if this pack is superseded. Whether the discontinuity a reviewer is seeing corresponds to an actual version boundary or is something else entirely.

It also makes the reverse query possible, which is the one that saves a production. Given a reference version, list every shot generated against it. When a fault is discovered in a pack, that query defines the blast radius immediately rather than by inspection. Without it, a production facing a bad reference has to review everything to find out what was affected.

The capture has to be automatic. Asking operators to type a version identifier into a field alongside every generation produces a record that is correct most of the time, and a record that is correct most of the time cannot be trusted for exactly the queries it exists to answer. If the generation tooling can write the version into the output metadata or a sidecar file, that is where it should come from.

7. When to Cut a Major Version, and When Not To

Major versions are expensive because they create a boundary that footage cannot cross. The decision to cut one should sit with production leadership rather than with the operator who noticed the problem, and it should be made against a clear test: does this change alter the face in a way an audience would register in a close up.

Some changes obviously qualify. Retraining on a substantially different image set. Aging a character for a time jump. Replacing the underlying reference person. Correcting a proportion error that has been visible since episode one. In each case the right move is a major increment and a deliberate decision about the boundary: either regenerate the earlier episodes, or place the boundary at a natural break in the story where the change reads as intentional.

Other changes look major and are not. Adding a costume. Adding an expression the original set did not cover. Adding a lighting variant for a night sequence. These are minor increments and they should stay minor, because promoting them to major creates unnecessary boundaries and trains everyone to ignore major versions as a signal.

The judgement call sits in the middle, usually around a reference set being extended with newly generated images of the same character. That extension can subtly shift the average the model draws from, particularly when the new images were themselves generated rather than sourced. The safe practice is to treat any extension of the core image set as major unless a comparison test against the previous version shows no perceptible difference across a standard set of test shots. Running that comparison takes an hour and it is the cheapest hour in the pipeline.

8. Retiring a Version Without Breaking the Archive

Superseding a version is not deleting it. When a pack moves from v2.4.0 to v3.0.0, the older version is marked superseded in the manifest, with the successor named and the reason recorded in one line. It stays readable, it stays retrievable, and it stops being offered as an option to operators starting new work.

The reason line matters far more than it appears to. Eighteen months later, when a sequel is commissioned and someone opens the character asset library, the difference between v2 and v3 needs to be legible to a person who was not on the original production. A one line note saying that v3 corrected a proportion error visible in close ups is the difference between a sequel that continues correctly and a sequel that quietly restarts the drift.

The same applies to the final state of the production. When a series delivers, the reference store should be closed with a record of which version of each character pack was current at delivery, which versions were used across the run and in which episode ranges, and which versions are safe to build on. That record is what turns a completed series into a franchise asset rather than a finished job, and it costs an afternoon at the end of a run that has been versioning properly all along. On a run that has not been versioning, it cannot be produced at all.

Axis AI Studios Perspective

Axis AI Studios is an AI native vertical drama production studio based in the Netherlands. Reference version control sits in the same layer as shot naming and prompt versioning: unglamorous production infrastructure that determines whether a long run holds together.

The position the studio works from is that character consistency across seventy episodes is not primarily a generation problem. The tooling is capable of holding a face. What breaks is the discipline around the assets that define the face, which get edited in shared folders, updated without announcement, and rendered irreproducible within weeks. Every consistency failure that survives to review is downstream of a reference asset that changed without a version.

The corollary is that this infrastructure has to exist before generation starts rather than being added when the first drift appears. A pack numbering scheme, an immutable published store, automatic capture of reference version at generation time, and a named owner for version decisions. Four things, all of them cheap at the start of a run and none of them retrofittable halfway through. Where a commission is expected to lead to sequels, the same infrastructure is what makes the character transferable to the next production rather than something that has to be rebuilt and rematched.

For platforms and IP holders who want to see how reference and asset discipline is specified in a production agreement before a series enters generation, write to business@axisaistudios.com.

FAQ

How many versions should a character pack go through on a typical seventy episode run?

Usually one major version and somewhere between four and ten minor increments, most of them wardrobe and expression additions as the story reaches scenes the original coverage did not anticipate. A run that produces three or more major versions has usually not finished its reference work before generation began, which is a scheduling problem rather than a version control problem. A run that produces none has either been unusually well prepared or has been editing in place.

Does this apply when a production uses reference images rather than trained models?

Yes, and the discipline is arguably more important there, because image based references are easier to change casually. There is no training run to act as a natural version boundary, so a folder can accumulate additions without anyone registering that the reference has moved. The numbering scheme, the immutable store and the per shot capture all apply unchanged.

What happens when the generation tool updates and the same reference pack produces different output?

The pack has not changed, so it does not get a new version. The tool and model version, which should be captured per shot alongside the reference version, is what changed. Treat it as its own boundary and test the existing packs against the new model before committing the run to it. Keeping the two identifiers separate in the record is what allows a production to tell a reference problem from a tooling problem after the fact.

Further Reading

For the pre production testing that should happen before any pack is published as a first version, the guide to testing character consistency across sessions covers the protocol and what a passing result looks like.

For what happens to versioned reference assets after a series delivers and a franchise begins, building an AI character asset library covers the difference between a temporary reference pack and a permanent asset.

For the tooling side boundary that sits next to the reference boundary, the guide to managing model changes mid production covers how to handle an update without breaking established character continuity.