Two Episode Lists Disagree. Reconcile the Editions Before Counting the Series

Two lists land in the same folder. One describes three episodes. The other describes four. Both came from people who know the series, and neither is a mistake.

The reflex is arithmetic: find the row that doesn't line up, decide which total is off by one, and start asking where the missing installment went. That reflex assumes both lists are counting the same thing. Usually they aren't.

A story-episode count, a packaged-program count and a language-asset count can each be correct while describing the same finished show. They are not interchangeable, and they do not add. Reconciling them is an identity problem before it is a counting problem. Decide what a row represents, establish which row in one list corresponds to which row in the other and on what basis, then report each total with the scope that makes it true.

What follows is about identity, not entitlement. A crosswalk can tell you that one program contains two installments. It cannot tell you whether those installments are cleared, delivered, or currently available to sell.

Name the unit behind every total

Start by preserving both lists exactly as they arrived, with their origins attached: who produced each one, when, and what decision it was built to serve.

That last detail does most of the diagnostic work. A delivery schedule and a commissioning note will disagree about episode counts as a matter of routine, because they are answering different questions. The delivery side describes files and packages. The commissioning side describes story. If the three-row list came from the department that packages material and the four-row list came from the department that ordered it, you may be holding two correct statements rather than one error.

Don't retype either list into your own shape yet. A derived sheet that has already smoothed the difference away cannot be traced back to the difference, and the difference is the thing you need.

Then ask, of each list: what is one row?

The candidates, in rough order of how often they get confused:

• A story episode. One narrative installment.
• An edit or manifestation. A distinct version of one installment: a recut, an extended version, an alternate title and credit block, a master at a different frame rate.
• A combined program. One deliverable containing two or more installments, commonly where a shorter pair was transmitted or packaged as a single block.
• A delivery asset. A file: a language version, a textless element, a subtitle sidecar, a separate audio mix.

Territory and language labels are not units. They are attributes hanging on a row. A list of three rows with three language columns is a list of three things, not nine. The moment a language becomes a row of its own, the list has changed species, and its total belongs in a different sentence.

A few cheap checks. If the rows of an "episode" list carry run times that swing between something like twenty-something minutes and roughly double that, suspect that some rows are programs. If a row's title is two titles joined, or a range, you are almost certainly looking at a combined program. If the same episode title repeats with different suffixes, you are looking at assets. And if the two lists share no identifiers at all, nothing but titles, stop comparing counts. You are comparing labels.

Now the illustration, which is fictional and stipulated rather than observed. Two received lists. List A describes three programs. List B describes four installments. The declared relationships are: P1 contains E1; P2 combines E2 and E3; P3 contains E4. The E and P labels are illustration labels, not source identifiers.

The mappings are stipulated, not inferred from titles. Treat the numbers as a declaration rather than a measurement.

That declaration is the whole disagreement. List A counts the packaging of one edition, in which E2 and E3 share a program. List B counts the story. The two numbers differ by exactly one combining decision.

Which means the wrong move is the obvious one. Do not "correct" the three up to four, or the four down to three, because one list has more rows. More rows is not more work. It is frequently just less packaging.

It is worth saying plainly that some disagreements really are about missing material. If two lists both claim to describe story installments, from the same edition, and they still disagree, you have a genuine gap. The unit question is the first test, not the only one. Run it first because it is cheap and it resolves most of these.

Establish the relationships before renumbering anything

The crosswalk is a document that makes a claim and shows its warrant. Every row should carry:

• the source list and the row's identifier exactly as received
• the unit that row represents
• its relationship to other rows, as parent, child, or sibling
• the basis of the match
• a status: confirmed or unresolved

The basis field is where a crosswalk earns its keep, so be strict about the hierarchy of evidence.

Weak: similar titles, matching order, plausible duration.

Medium: consistent numbering across two lists that share a common origin.

Strong: an owner-confirmed identifier, a delivery specification that names the material, or an inspection of the item against a known reference.

Titles and order flag questions; they don't settle them. Duration is a slightly better flag and still not proof. A program that pairs two installments will often run long, but credits, recaps, title cards and frame-rate conversion all move run time around. Transmission order and production order differ often enough to be useless on its own.

Translated titles matter less than they seem to, because they are the easy case. Two lists naming the same installment in different languages look like a reconciliation problem and are mostly a labeling problem. The hard case is the combined program, where naming gives you nothing at all. P2's title does not tell you whether it is one installment or two. Only the record does.

Which brings up the shape of the relationship. P2 combines two installments, so the crosswalk needs E2 and E3 as two children of one parent, drawn as two rows. It does not need a synthesized row like "E2–E3" sitting where an episode belongs. That invented entity will quietly raise your story count by one in whatever downstream sheet aggregates the child column, and it will be very hard to find later, because it looks exactly like an episode.

Everything that cannot be resolved stays outside the confirmed map. In the illustration, one further item exists: U1, a delivery that arrived with a filename asserting a fifth installment. Nothing in the confirmed record supports a fifth installment. U1 might be a re-delivery, an alternate cut, a mislabeled export, or something not yet described. The filename is a label someone typed, not an identity, and it must not be allowed to create an episode by naming one.

So U1 gets a row, three fields and no count: what is known (it exists, where it is, what it is called), what is not (which entity it belongs to), and who owns the answer. For a real series, that owner holds authoritative records for the edition: the rights holder's operations contact, the facility that produced the program, or the department maintaining the edition's own documentation. Your crosswalk is not a source. A registry is not a source for your inventory either, though it can be a source for the shape of the problem.

Which is roughly what the public records can and cannot do here. EIDR's "How We Work" page, in a reading recorded on 2026-09-18, describes identity being carried at several levels (series, season, episode, edit, manifestation) and describes compilation grouping, where one grouping covers more than one item. That is useful because it confirms the levels you are trying to keep apart are recognized distinctions rather than a private invention. It does not tell you what is in anyone's vault, and it will not resolve a mislabeled record or establish rights.

Choose the presentation that preserves the editions

Once the relationships are down, decide how to show them. There are two defensible routes.

Edition-native. Each received list remains the canonical description of its own edition, accompanied by a difference note that says, in a sentence, what changed and why. This is the honest route when the buyer will inspect one specific edition, and when the people who fetch material work from the numbers already printed on it. Its cost is conversational: a reader comparing two packets sees a one-row gap and asks about a missing episode. The difference note has to sit at the top, not in a footnote.

Common map with edition bundles. A single spine of underlying installments, with each edition's packaging shown as bundles hanging off it. This is the better route when the acquisition conversation is about story scope, how much story is being bought, or when the buyer is weighing one edition against another. Its cost is implicature. A clean spine suggests that any bundle can be split and reassembled, and that a cut in one edition is the same cut as the corresponding item in another. Both suggestions are usually false.

If you take the second route, three notes carry the weight. This spine is an identity map, not a conforming plan. Durations are not implied to match across editions. And assets attached to a combined program are program-scoped: the two language assets mapped to P2 cover E2 and E3 as delivered together, and they cannot be split to supply E2 and E3 as separate deliverables without a new operation. If a buyer wants the installments apart, in two languages, that is four episode-level assets, and it is a production question rather than a counting question. Better to say so than to let the map imply it is handled.

Choose by the conversation, not by preference. On either route, keep the source numbering as an attribute on every row. When someone walks to the shelf, they will search by the identifier written on the material, not by the ID you assigned in your map.

State non-additive counts and expose unresolved delivery

The counts come out as separate statements, each with the scope phrase that makes it true. For the illustration:

Confirmed underlying episodes: 4. Scope: installments established by owner-confirmed identifiers in the crosswalk.

Programs in the named edition: 3. Scope: the edition in which E2 and E3 share a program.

Mapped delivery assets: 6. Scope: two language assets attached to each of the three programs in that edition.

Unresolved: 1. U1, unmapped, identity owner named, status open.

Four, three, six. They do not add to thirteen, or to anything. The units nest by construction: programs are made of installments, and assets are renderings of programs. Summing them counts the same finished material two or three times over and produces a number that means nothing in any conversation you might have with it.

Two failure modes live in that paragraph and deserve naming separately.

The first is scope drift on the asset count. "Six assets" is not "six language versions of the series." It is two language assets across three programs. A reader skimming a sheet can convert that into six dub languages or six territories without noticing, and the error travels. Write the scope phrase so it cannot be read that way.

The second is mistaking a permission for a file. In the MovieLabs Avails schema, the recorded reading of the printed pages 14 and 22–24 distinguishes language restrictions from fulfillment information, alongside separate handling of title, edit and manifestation, supplied episode-count semantics, and transaction geography and dates. The practical consequence is that a language column in an avails-style workbook may be telling you where something may be exploited, not what has been delivered. Those are two different lists that can have identical row counts. Decide which one you are holding before you count it.

Two limits apply to that paragraph. A dated reading of specific pages is not a full schema audit, and a specification is not a license, not a confirmation of current availability, and not a universal spreadsheet convention. Those pages were not reopened for this piece, so before a schema-specific column name enters a deliverable, go back to the cited pages rather than to memory.

Then the handoff. The crosswalk's identity information goes into the sales sheet. It does not go in as a conclusion about availability. Identity confirmed, delivered, cleared and currently available are four different fields with four different kinds of evidence, and the crosswalk populates only the first. The unresolved item travels too, with its status visible rather than quietly dropped, and with the name of whoever can close it.

Nothing here repairs a missing deliverable, and nothing here establishes that rights cover what exists. It establishes what each list was counting.

A crosswalk with its bases recorded, three scoped counts, and a short list of open identities. That is the package worth sending, because it lets the next person either confirm the mapping or correct it, which is the actual job. A reconciliation exists to be checked.

The failure it prevents is specific: a tidy total that hides an uncertain identity or an unresolved right, gets quoted in a deck, and comes back to you in a negotiation with your own name attached to it.

Meanwhile the gap between three and four has an answer, and the answer is a sentence. In this edition, two installments share one program. Put that in the difference note, and the disagreement stops being a discrepancy and becomes a description.

Frequently asked questions

Why can two episode lists disagree without either being wrong?

They may be counting different units. A story-episode count, a packaged-program count, and a language-asset count can each be correct for the same finished show. The lists are not interchangeable and do not add; the problem is identity before it is counting.

What should you ask about each list before comparing totals?

What is one row? Candidates include a story episode, an edit or manifestation, a combined program containing two or more installments, or a delivery asset such as a language version or subtitle sidecar. Territory and language labels are attributes, not units.

How should a crosswalk record relationships?

Each row should carry the source list and identifier exactly as received, the unit it represents, its relationship as parent, child, or sibling, the basis of the match, and a status of confirmed or unresolved. For a combined program, show two children under one parent rather than inventing a synthesized episode row.

What should happen to an unresolved item like a filename asserting a fifth installment?

It stays outside the confirmed map. It gets a row, three fields, and no count: what is known, what is not, and who owns the answer. A filename is a label someone typed, not an identity, and it must not create an episode by naming one.

Why not add the episode, program, and asset counts together?

The units nest by construction: programs are made of installments, and assets are renderings of programs. Summing them counts the same finished material multiple times. Report each total with its scope, such as confirmed underlying episodes, programs in the named edition, mapped delivery assets, and unresolved items.