Update a Pitch From a Revised Script When the Production Page Numbers Are Locked

Locking pages makes a promise: page 47 will still be page 47 on the day someone shoots it. The cost of that promise is that a revision can no longer announce itself by shoving everything downstream. Instead you get a 47A, and sometimes a 49 that is simply gone, with a line in the issue notes saying it was dropped.

Read that packet as a document and it looks broken. Read it as a set of instructions and it is exact — provided you know what it is instructing you to build.

So the honest answer to "how do I update my pitch from these pages" is: not yet. First resolve what arrived into one complete, identified reading source. Two questions decide the whole operation. Is this a complete reissue or a packet of replacement pages? And if it's a packet, does the packet account for every anchor the issue information names? Only a source that answers the question that applies to it — a current, owner-confirmed complete reissue, or a packet that accounts for every named anchor — is something you can safely read for story changes and cite in a deck.

Everything below assumes locking already happened. Nothing here asks you to lock a development draft or to change a production script's pagination.

Decide which delivery you actually have

Two deliveries arrive under nearly the same name and require opposite handling.

A complete reissue is one document, labeled as a version, containing the entire script as of that version. You read it directly. You still have to confirm which version it is and that the sender has the standing to say so.

A replacement-page packet is a subset of pages plus instructions establishing what each supplied page does and what happened to the anchors you didn't receive. You read the instructions, not the packet as a continuous script. You use them to assemble the reading source.

Ask the owner which one this is — the person who can authorize the issue, not whoever forwarded the email. This isn't bureaucratic caution. A packet mistaken for a reissue sends you hunting for two-thirds of a script that was never promised. A reissue mistaken for a packet sends you looking for issue instructions that don't exist.

What you cannot use is appearance. Colors, timestamps, filenames and folder positions all correlate with revisions, and none of them establish authority. Revision colors are conventions agreed among departments; they are not proof of which issue a file belongs to. A file named SCRIPT_v14_FINAL_LOCKED(2).pdf is named that by whoever named it. If nobody can confirm the delivery's role, that's the first missing item, and it outranks every page-level question that follows.

Locked page numbers are identities, not positions

Once pages are locked, a page number stops being a location in a document and becomes a name. Final Draft's knowledge base article on locking pages — updated February 19, 2025, and checked in our source work in September 2026 — describes the machinery: fixed page identities, pages inserted under lettered labels, omissions that are marked rather than silently dropped, and the requirement that issued pages and omissions be accounted for. It also cautions against locking during ordinary writing and redrafting, which is good advice and not this article's problem.

What that documentation establishes is the mechanism. It cannot tell you which issue of your project is current, and it cannot tell you whether the packet in front of you is the one your producer is reading. Those questions belong to the issue information and the owner. There is also an unlock path if a lock was applied by mistake, but that's a recovery operation, not part of this workflow.

Two consequences of identity-as-address break naive handling, and both are easy to commit inside a spreadsheet:

• A lettered page is not a number with a decoration. 5A sits between 5 and 6 because it belongs there. If your tooling strips the letter — a column typed as numbers, a parser reading labels as integers — then 5, 5A and 5B all collapse into 5. Three distinct pages become one.
• Plain string sorting fails differently. Sorted as text, "10" comes before "4". The last page of your packet ends up first.

Use the order the issue supplies. If the issue doesn't supply one, that's a question, not a license to invent a sequence.

Build the issue map before you read for story changes

The map is a table with a row per anchor and three columns: the anchor label, its state, and where its authorized content comes from. Four states cover most packets — unchanged, replaced, inserted, explicitly omitted — plus a fifth for the failure case, which we'll get to.

Reading for story comes after, for a reason that has nothing to do with tidiness. If you read assembled pages before you know which anchor 6 you're holding, you absorb a version of a scene, and then you have to un-absorb it. Worse, you start the pitch work on top of that absorption, and the synopsis quietly encodes a scene that no longer exists.

The map has a second product beyond correctness: provenance. Each row names the source of that anchor's text — baseline issue and page, or revision issue and page. When a producer asks where a line comes from, "revision issue, page 5A" is an answer. "One of the PDFs" is not.

An omitted page is not a missing page

These two conditions feel similar and demand opposite responses.

A marked omission accounts for an anchor. The issue says page 7 is out. It has no content and needs none. Your map records it and you move on.

An absent required page accounts for nothing. If the instructions replace page 5 and page 5 isn't in the delivery, you have a gap, not a deletion. If they insert 5B and no 5B appears, same thing. Nothing in the packet tells you what those pages say, and nothing tells you the story no longer contains them.

The tempting error is quiet and plausible. Facing a hole where 5B should be, you might leave the baseline 5 in place, or let page 6 carry both jobs, or lift a paragraph that "fits." The assembled script can then read cleanly — dialogue answers, scenes close — while representing a story that no longer exists. Plausible continuity is the dangerous failure mode here, precisely because nothing in the reading experience signals that it happened.

Hence the rule that governs the whole operation: an omission notice resolves an anchor; a missing delivery blocks assembly.

Two packets, same instructions, one stop

What follows is a teaching exercise with invented labels, not a real script's issue list. Baseline anchors run 4 through 10. The issue says 4, 6 and 8–10 are unchanged; 5 is replaced; 5A and 5B are inserted; 7 is explicitly omitted.

Delivered complete, the manifest closes:

Reading order: 4, 5, 5A, 5B, 6, 8, 9, 10. Nine anchors, eight pages of text, one accounted-for gap. The map is closed, so you assemble — and only now do you read for story.

One join deserves a second look: the bottom of 6 now runs into the top of 8. Read across that boundary specifically. A duplicated stage direction, an orphaned half-line, a scene now ending on a beat that depended on 7 — those surface at joins, not in the middle of pages. Check the others too (4→5, 5→5A, 5A→5B, 5B→6). Where a join doesn't work, that's a question for the script owner, not a repair you make in the reading copy.

Now change one fact. Same instructions, same baseline, but the delivery contains no 5B and says nothing about it.

The omission notice for 7 still does its job, and you should not go looking for that page. But 5B is unresolved. Its absence is not information about the script; it's a hole in the delivery. Eight anchors out of nine are resolved, and the ninth is the one that matters, because the page between 5A and 6 is unaccounted for. The packet cannot be assembled. Stop, and send a request naming the anchor, the issue and what you need: the missing 5B, or an owner-confirmed complete reissue.

An earlier synthetic check of this manifest exists in our notes, but the file is no longer available and its recorded result has never been re-run. No native packet was tested for this article. Treat the example as worked reasoning about a labeled construction — the logic, not a verified product behavior.

Two routes to a complete source, and what each costs

With the map closed, you have a choice worth making deliberately.

Reconstruct from the packet. You assemble baseline and issued pages into one reading copy. What you gain is page-level provenance: every anchor traces to a named issue and page. What you pay is assembly labor and a larger error surface — nine anchors is trivial, but a hundred-page feature carried across three revisions is a sequence of chances to misplace a page. This route also assumes the issue list is complete and legible, which is not guaranteed.

Take an owner-confirmed complete reissue. One document, one version, no joins. What you gain is speed and a smaller error surface. What you pay is provenance: a reissue is easier to read, but it does not by itself prove it is current. "Complete" and "current" are different properties, and a reissue delivers the first without necessarily delivering the second. Take this route and you still need the owner to confirm the version.

The routes can be combined — reconstruct from the packet, then ask the owner for a reissue to check against. Where the two disagree, the disagreement is itself information, and usually information about which issue governs.

What neither route does is approve anything. Assembling a reading copy tells you what the script says. It does not tell you the script is approved, and it does not authorize you to make or accept production revisions. If the issue instructions conflict with each other or with what the owner tells you, the outcome changes: you have a missing-information request, not an inferred assembly.

Carry the source identity into the pitch update

Label the assembled file for what it is — reading copy assembled from this baseline and this revision issue, per the issue list, on a date — and keep it distinct from any approved issue. If your folder structure can't separate those two things, fix that before you write a sentence.

Then read for what a pitch actually depends on: premise, events, characterization, and the specific passages you quote or paraphrase.

Locked pages change the audit you run on the deck you already have, and the distinction is worth holding clearly. Locking protects addresses, not content. A page number in a locked script still points where it pointed. What may have changed is what's written there. Sort every page reference in your deck against the manifest:

• Unchanged anchor. The address is still valid. Check that the line you quote or summarize is actually the line on that page — unchanged means the page wasn't reissued, not that you remembered it correctly.
• Replaced anchor. The address holds; the content moved. Every quote, paraphrase and characterization attached to that page gets rechecked.
• Inserted anchor. Pages 5A and 5B didn't exist when you wrote the earlier draft. Decide whether the deck should cite them, and consider who is reading. A citation to 5B assumes your reader holds the revision issue; anybody holding the baseline sees an old page 5 and no 5B at all. If the new material is worth citing, cite it by scene and description rather than by letter.
• Omitted anchor. Your reference to page 7 now points at nothing. Remove it, redirect it to wherever the material went if the owner can tell you, or drop it. Don't leave a page number in a deck with no page behind it.

One more caution. Whatever your pitch says about the script, it now says it about a specific identified source. If a change you're describing came from reading a join rather than reading a page, mark it as a question for the script owner. Assembly is not approval, and a pitch that quietly promotes an inferred scene change into a statement of fact is a problem you'll be explaining later, to someone who has the real pages in front of them.

Ending with either outcome

Two endings are legitimate here, and you should know which one you're in.

The first: a complete source map, every anchor accounted for, every join inspected, a labeled reading copy, and a pitch audited against it. That's a finished operation.

The second: a manifest with one row that reads required, not supplied, and a short specific message to the owner naming the anchor, the issue and what you need. That's also finished — and better than a deck built on a page you made up by accident.

What isn't legitimate is a synopsis assembled across a gap. If you catch yourself writing "the scene across pages 5–8 plays differently now" while 5B is still missing, stop. The source isn't ready, and neither is the pitch.

Frequently asked questions

What must be resolved before reading locked pages for story changes?

First resolve what arrived into one complete, identified reading source. Two questions decide the operation: Is this a complete reissue or a packet of replacement pages? And if it is a packet, does the packet account for every anchor the issue information names? Only a source that answers the question that applies to it, either a current owner-confirmed complete reissue or a packet that accounts for every named anchor, is something you can safely read for story changes and cite in a deck. Until then, the honest answer to how you update the pitch is: not yet.

Why do revision colors, timestamps, filenames or folder positions not establish which issue you have?

Appearance correlates with revisions, but none of it establishes authority. Revision colors are conventions agreed among departments, not proof of which issue a file belongs to. A file named SCRIPT_v14_FINAL_LOCKED(2).pdf is named that by whoever named it. Ask the owner, the person who can authorize the issue rather than whoever forwarded the email, which delivery this is. If nobody can confirm the delivery's role, that is the first missing item, and it outranks every page-level question that follows.

What is the difference between a marked omission and an absent required page?

A marked omission accounts for an anchor. The issue says page 7 is out; it has no content and needs none; your map records that and you move on. An absent required page accounts for nothing. If the instructions replace page 5 and page 5 is not in the delivery, or they insert 5B and no 5B appears, you have a gap rather than a deletion. Do not leave the baseline page in place, let page 6 carry both jobs, or lift a paragraph that fits. The rule is that an omission notice resolves an anchor, while a missing delivery blocks assembly.

What should the issue map contain, and why build it before reading for story?

The map is a table with a row per anchor and three columns: the anchor label, its state, and where its authorized content comes from. Four states cover most packets, unchanged, replaced, inserted and explicitly omitted, plus a fifth for the failure case. Build it before reading for story because if you read assembled pages before knowing which anchor 6 you are holding, you absorb a version and then have to un-absorb it; the synopsis can quietly encode a scene that no longer exists. The map also gives provenance, so when a producer asks where a line comes from, 'revision issue, page 5A' is an answer.

How should an updated pitch treat inserted and omitted anchors?

Inserted pages 5A and 5B did not exist when the earlier draft was written. Decide whether the deck should cite them, and consider who is reading: a citation to 5B assumes your reader holds the revision issue, while anybody holding the baseline sees an old page 5 and no 5B at all. If the new material is worth citing, cite it by scene and description rather than by letter. An omitted anchor is different: your reference to page 7 now points at nothing, so remove it, redirect it to wherever the material went if the owner can tell you, or drop it. Do not leave a page number in a deck with no page behind it. For unchanged anchors, check that the line you quote or summarize is actually the line on that page; for replaced anchors, recheck every quote, paraphrase and characterization attached to that page. If a change came from reading a join rather than reading a page, mark it as a question for the script owner; assembly is not approval.

Further reading

• Two Script Versions Support Different Film Pitches. Which One Are You Writing? — When the revision leaves two plausible creative bases rather than one source map, this shows how to ask whether the change is adopted, exploratory, or superseded.