How to Split a 70 Episode Series Into Generation Blocks So Two Operators Never Collide

Two operators. One series. Episode 34 comes back with the wrong face.

Nobody did anything wrong. Operator A updated the lead character reference on Tuesday because the eye line was drifting in the office interiors. Operator B had already pulled the previous version into a batch of eleven shots for episodes 31 through 36 and queued them overnight. Both decisions were correct in isolation. The output is still unusable, and the only way to find out was to review the block and notice that the protagonist does not match herself across an episode boundary. Collisions like that are not a skill problem. They are a structure problem, and they scale with the number of people touching the series.

The fix is not better communication. Communication degrades under volume, and a 70 episode vertical drama series carries roughly eight hundred to twelve hundred clips depending on coverage density. No messaging discipline survives that. What survives is a split that makes collisions structurally impossible, where each operator owns a defined range of work and the shared assets underneath it have a single writer and many readers. This piece covers how to draw that split, what to lock, and how to test it before committing the whole series.

1. Why Two Operators on One Series Collide in the First Place

Collisions happen because generation work looks parallel and is not. On the surface, episode 12 and episode 48 have nothing to do with each other. Different scenes, different beats, different shot lists. Underneath, both operators are reading from the same character reference set, the same location library, the same light locks, and the same prompt library. The surface is parallel. The foundation is shared, and the foundation is where the damage happens.

There are four collision types worth naming, because they fail differently and need different controls. The first is a reference overwrite, where one operator revises a shared asset that another operator has already consumed. The second is a silent divergence, where two operators solve the same problem two different ways and neither knows the other did it, so the series carries two visual answers to one question. The third is a sequence gap, where a scene spans an episode boundary that is also an ownership boundary and neither operator generates the connective shots because each assumed the other would. The fourth is a queue conflict, where both operators submit large batches against the same compute allocation and each one waits on the other without knowing why.

Only the fourth is a scheduling problem. The first three are ownership problems, and ownership is what a block split actually assigns. If you take one idea from this piece, take that one: you are not dividing episodes between people, you are assigning write authority over assets and read authority over everything else.

2. The Unit of Ownership Is the Block, Not the Episode

An episode is the wrong unit. Episodes in vertical drama run around ninety seconds and frequently cut mid scene, so continuity crosses episode boundaries constantly. Hand operator A episodes 1 through 35 and operator B episodes 36 through 70 and you have drawn a line through whatever scene spans that gap, making the sequence gap described above a permanent feature of the series.

The correct unit is a generation block, which is a contiguous run of episodes that begins and ends on a scene boundary and shares a coherent set of locations and characters. Blocks are not equal in length. A block might be five episodes if those five episodes are a single high intensity confrontation in one interior, and it might be fourteen episodes if those fourteen cover a slower stretch across three recurring locations with a stable cast. The block is defined by production coherence, not by arithmetic. This is the same logic that underpins a work breakdown structure in any other delivery discipline, where the lowest level package is the smallest unit a single owner can complete and verify without reaching into someone else.

Practically, a 70 episode series decomposes into between eight and fourteen blocks. Fewer than eight and the blocks are too large to hand over or reassign cleanly. More than fourteen and you spend more time on handovers than on generation. Each block gets exactly one owning operator, and that ownership does not move mid block short of an emergency.

3. How to Draw Block Boundaries That Hold

Start from the scene list, not the episode list. Lay out every scene in the series in story order with its episode span recorded against it. Boundaries can only fall where a scene ends and another begins, which immediately eliminates most of the arbitrary cuts that an episode based split would produce. Then look for the natural seams: a location change, a time jump, the departure of a character from the story for several episodes, the end of an act.

Prefer boundaries where the shared asset load changes. If episodes 1 through 9 live almost entirely in two interiors with three characters, and episodes 10 onward move to a new location set with two added characters, that transition is the strongest available boundary. Each block then has a narrower reference footprint, which reduces the shared assets either operator reads, which reduces the collision surface. Boundaries at the point of maximum asset change are the cheapest you will get.

Record each block in one place with five facts: the block identifier, the episode span, the scene span, the owning operator, and the complete list of shared assets the block reads. That last field is the one people skip, and it is the one that makes the model work. If you cannot list the assets a block consumes, you cannot tell whether a planned revision affects a block in flight.

4. Shared Elements Are the Real Collision Surface

Everything inside a block is private to its owner. Shot level prompts, seeds, retake attempts, intermediate selects, working notes. None of that is shared and none of it can collide. The collision surface is only the set of assets that more than one block reads, and that set is smaller than most teams assume. Naming it precisely is most of the work.

Character references

Character reference sets are the highest risk shared asset by a wide margin, because every block reads them and because a character revision is visible to a viewer within one frame. Treat the reference set for each named character as a single versioned object with an explicit version identifier that appears in every generation record. Operators read a version. They never read the latest. The difference matters: reading the latest means a block in flight silently changes underneath the operator, and reading a version means the block completes against a known state and any revision applies to the next block instead.

Location and set references

Location references collide less often but recover worse. A character inconsistency can be fixed by regenerating the affected shots. A location inconsistency often means regenerating every shot in a scene, because the room has to match itself across the whole sequence or the cut will not hold. Version location references the same way as characters, and resist the temptation to improve a location reference mid series. An adequate room that is consistent beats a better room that is consistent in only some of the episodes.

Light and grade locks

Light locks describe the lighting state for a location at a given story time: direction, quality, colour temperature, intensity relationship between key and fill. Two operators generating the same location at the same story time must be reading the same lock or the cut between their blocks will flicker. Lock definitions should be written out in plain text rather than carried in reference frames alone, because a text definition can be read, compared, and audited, and a reference frame can only be looked at.

The prompt library

The prompt library sits in a different category because operators both read and write to it constantly. Split it: a locked core only the generation lead revises, and operator scratch areas where anyone can develop a construction before promotion into the core. Promotion is a deliberate act with a review attached.

5. The Write Lock Rule for Shared Assets

Here is the rule that eliminates the overwrite class of collision entirely. Every shared asset has exactly one writer at any moment, and while a block that reads that asset is in flight, the asset is frozen. Revisions queue. They do not apply.

This is the same mutual exclusion logic that governs any critical section in a concurrent system, and it works for the same reason: the only reliable way to stop two writers from corrupting shared state is to make concurrent writing structurally unavailable rather than merely discouraged. In practice the generation lead holds write authority over all shared assets. Operators propose revisions. The lead applies them at block boundaries, not inside blocks, and when a revision lands it gets a new version identifier and the affected blocks are recorded.

Operators will push against this, and their objection is legitimate: they can see a problem with a shared asset and they are being told to keep generating against the broken version. The answer is that they log the defect and finish the block, and the revision applies to the next block that reads that asset. The cost is a small number of shots that carry a known imperfection. The alternative cost is a block that carries two different answers inside it, which is not a known imperfection but a visible break. Known imperfection is recoverable at the retake stage. A mid block divergence usually is not.

One exception, carved out explicitly. If a shared asset is producing output that is unusable rather than merely imperfect, the block stops. You do not generate into a wall to protect a process rule. Stopping a block is the decision of the lead, and it should be rare enough that each instance earns a note in the retake log.

6. Naming and Path Discipline Inside a Block

A block split only holds if you can tell at a glance which block a file belongs to. That means the block identifier is part of the file name, not part of a folder structure that someone will flatten during a delivery handoff. Vertical drama productions move a lot of files between generation, review, and edit, and folder context is the first thing lost in that movement.

Keep the identifier short and sortable. A two character block code at the front of the name, followed by episode, scene and shot, sorts into story order inside any block and groups cleanly across blocks. Carry the consumed asset versions in a sidecar record keyed to the file name rather than in the name itself, which keeps the name readable once the asset list passes three or four items.

The payoff arrives at review. When a reviewer flags drift in a run of shots, the names say immediately whether the run sits inside one block or crosses a boundary. Inside one block, the cause is almost always a prompt or seed issue the owning operator can address. Across a boundary, it is almost always an asset version mismatch, which is a different investigation. Telling those apart in seconds rather than hours is most of what naming discipline buys.

7. The Handover Points Between Blocks

Block boundaries need an explicit handover even when the same operator owns both sides. The handover is a short record: which shared asset versions the completed block consumed, which shots are carrying known imperfections and why, which prompt constructions were developed during the block and should be considered for promotion, and what the last frame state of the final shot is so the next block can open against it.

Write it down at block completion, not at the end of the series. A handover written four blocks later is reconstruction, and reconstruction loses the detail that mattered. The record exists so whoever opens the next block does not have to ask, and so that if an operator becomes unavailable the finished block stays legible.

Where a scene genuinely spans a boundary, which should be rare if the boundaries were drawn properly, assign the connective shots explicitly to one side. Both operators should be able to say which of them owns the bridge. Unassigned bridges are the most common source of a delivered series arriving with a missing beat that nobody caught until platform ingest.

8. How to Test a Block Split Before Committing 70 Episodes to It

Do not roll a block split across a full series on the strength of a plan. Test it on two adjacent blocks first, with both operators working concurrently, and look specifically for the four collision types. Run the test long enough that at least one shared asset revision gets proposed, because the write lock rule is the part most likely to break under real pressure and you want to see it break while the cost is two blocks rather than seventy episodes.

Three signals tell you the split is holding. First, neither operator had to wait on the other for anything other than compute. Second, the cut across the block boundary holds without retakes attributable to asset mismatch. Third, the handover record from the first block was sufficient for the second block to open without a conversation. If any of the three fails, the boundary is in the wrong place or the shared asset list was incomplete, and both are cheap to fix at two blocks.

Also measure the retake rate inside each block against the rate a single operator was producing on the whole series. A block split should not raise it. If it does, the usual cause is blocks drawn too small, so attention goes to handovers instead of the work, and the fix is to merge adjacent blocks until the rate settles.

Axis AI Studios Perspective

Axis AI Studios runs vertical drama production as an industrialised pipeline, and the block model is how that pipeline absorbs more than one operator without losing continuity. The structure described here is the structure we use: blocks drawn on scene boundaries and asset transitions, one owning operator per block, shared assets versioned with a single writer, and a written handover at every boundary. We hold it because it is the only approach we have found that keeps a 70 episode series coherent when the generation load exceeds what one person can carry.

What we claim is the production practice, not a universal law. The block count for a given series depends on its location density and cast size, and the boundaries come out of the scene list rather than a template. We work this way across the series we deliver, including production work for Den Tolmor and Good Fight Production LLC and for HolyWater, where coherence across a long episode run is the deliverable rather than a nice property of it.

For the operators reading this: absorbing collisions by being careful is structural work done with personal attention, and it does not scale however good you are at it. The structure is supposed to carry that load instead of you.

If you are planning a series that will need more than one generation operator and want to talk through how the blocks should fall, write to business@axisaistudios.com.

FAQ

How many generation blocks should a 70 episode series have?

Usually between eight and fourteen. The number comes from where the scene and asset boundaries fall, not from dividing episodes evenly. Fewer than eight produces blocks too large to hand over or reassign. More than fourteen produces so many handovers that coordination cost exceeds coordination benefit. If your scene list suggests a number outside that range, check whether you are drawing boundaries at episode breaks instead of scene breaks.

Can two operators ever work inside the same block?

Not on generation. Two operators inside one block reintroduce every collision type the split exists to prevent, because the block is the unit of write authority. What does work inside a block is a split between generation and review, since those roles read the same assets but write to different places. If the generation load inside one block genuinely needs two people, the block is too large and should be split.

What happens when a shared reference is clearly wrong and a block is still in flight?

Log the defect, finish the block, apply the revision at the boundary. Shots generated against the imperfect version carry a known issue addressable as a retake, which is recoverable. A revision applied mid block produces a visible inconsistency inside a continuous run, which usually is not. The exception is output that is unusable rather than imperfect, in which case the block stops and the generation lead decides what happens next.

Further Reading

For how the prompt library underneath a block split should be organised so multiple operators can read from it without diverging, the prompt library structure for four generation operators covers the locked core and scratch area model in detail.

For the file naming layer that makes block ownership visible at a glance, the shot naming conventions guide covers field order, versioning and the failure modes that bad names produce downstream.

For what has to travel with a completed block when it moves to the edit, the shot handoff between generation and edit covers the context packet and why handoffs lose information without one.