Correct a Sent Treatment Without Leaving Two Versions in Circulation
Correct a Sent Treatment Without Leaving Two Versions in Circulation
People assume the hard part of a correction is the editing. It isn't. Editing is the part with an undo button. The hard part is that you sent version 03 into a room, several people started making decisions with it, and there are now two things alive: the sentence you fixed and the belief you didn't.
The instinct after catching an error is to fix the file and resend. Updated link, "please use this." That instinct is correct as far as it goes, and it usually stops too early. A resent link corrects the people who open it, notice what moved, and revise what they had already concluded. If any part of that is left to chance, you haven't corrected the treatment. You've produced a current file and a set of readers still working from its predecessor.
So the question is not how to edit the document. It's what the document let people believe, and which version they think they're holding now. Those two questions drive everything below.
Classify the error by its consequence
The wrong way to sort an error is by how large the edit is, or how embarrassing it feels. Neither tells you what to do. A single changed word can be the most consequential sentence in a treatment — "secured" versus "proposed" is one word, and someone may have budgeted against it. A whole paragraph of retuned description that changes nothing anyone would do is polish. Size and materiality are different axes, and only one of them governs the correction.
The questions that actually sort the error are these. What could a recipient reasonably have concluded from it that isn't true? And which subsequent action could rest on that conclusion? The first question tells you whether you have a correction at all. The second tells you how far it has to travel.
Run a few categories through those questions and the spread shows up quickly. A typo that doesn't alter a conclusion usually fails both questions: no false belief, no dependent action. A wrong image or a misattached file can trigger the first even when nothing has been built yet, because someone may have been looking at the wrong reference — and if the wrong document went to the wrong recipient, that may be a confidentiality question rather than a copy question. A changed scene changes what the film is, which is more than a defect. An unsupported product statement matters even before anyone acts on it, because unsupported claims get repeated. An unapproved production promise — a location called locked, a name called attached, a deliverable called included — commits resources and people, and those commitments move independently of your document.
Notice that these aren't ranked by severity in the abstract. They're ranked by reliance: what did the error let someone do, or stop doing. That reframing changes the notice you write, because the notice isn't describing the edit. It's describing the belief that has to change and the action that follows from it.
Prepare one identifiable corrected version
Correct the smallest part that needs correcting, then check what else in the treatment refers to it. A heading, a scene number, a location named in two places, a claim repeated in the summary and again in the body — fix page 6 alone and leave page 11 still asserting the old location, and you haven't removed the ambiguity. You've added a third state to it.
Then give the replacement a version identity that another person can use without asking you what it means. It has to be possible for a reader to say "I have version 03" or "I have version 04" and for those statements to describe one thing each. Appending "FINAL" or "FINAL_v2" does not do this. The word final is a mood, not an identifier; it tells the reader how you feel about the file, not which file supersedes which. "Version 04 supersedes version 03" is an identity.
Keep the record of what was sent. Superseding is not erasing. The old version stays visible as the thing that went out, because people need it to check what they acted on: the director who built a sequence on the rooftop, the producer who scheduled around it, the client who repeated a line from the summary. Quietly deleting the record so the error looks like it never happened destroys exactly the trail those people need, and it's a worse move than the error. What you retire is the old version's authority, not its existence.
One more distinction saves a lot of confusion later: a replacement is not an option. A replacement says "this stands in for that." An option says "here is an additional idea, also live." If you send version 04 as authoritative and then float "v04 — alternate ending" as a second file, you have rebuilt the ambiguity you were trying to close, now with a version number that looks settled. If an option is genuinely open, call it an option and name the decision it's waiting on. Don't let it ride along under the authority of the corrected version.
Choose a correction message proportionate to the change
Here is where the notice weight has to match the change weight. To make the difference concrete, take one clearly fictional treatment — call it the Lantern spot — and two errors it might have contained. Neither notice below is a message to send; they are shapes drawn for this article, with bracketed placeholders standing in for real details.
If the only problem were a mislabeled scene heading, the notice would look like this.
Subject: Lantern spot treatment — heading corrected; version 04 replaces version 03
The treatment sent on [date] is version 03. On page 6, the scene heading reads "SCENE 9 — HARBOR." The scene on that page is the boathouse, and always was; only the heading was wrong. Version 04 corrects it to "SCENE 9 — BOATHOUSE."
Nothing else changes. No shot, line, or duration moves. Version 04 is the version to work from, whether or not page 6 is part of what you're doing right now.
If the problem were instead the location claim, the notice would look like this.
Subject: Lantern spot treatment — rooftop not secured; version 04 replaces version 03
The treatment sent on [date] is version 03. Version 03 states that the rooftop location is secured for the shoot window. That is not accurate. The correct status is proposed; access unconfirmed.
This affects Sequence C, which is built around shooting from the rooftop. Anything that assumed the location was in hand — the shooting order, the coverage plan, the cost line tied to that day — is resting on an assumption that isn't settled. The producer is the route for this. Until the access question is resolved, the rooftop shouldn't be treated as confirmed, and resolving it belongs with the owner rather than with this note.
Version 04 replaces version 03. Everything else in the treatment is unchanged.
Put the two side by side and the information burden is the real difference. The first notice asks the reader to locate one thing and confirm that nothing else moved. It can be discharged by opening page 6. The second asks the reader to drop a belief they may already hold, work out which of their own actions depended on it, and route a question to an owner instead of settling it themselves. That burden cannot be discharged by opening the file, because opening the file only shows the new sentence. The work is in checking what the old sentence caused.
A correction message is not a summary of the edit. It's an instruction about what to stop believing and what to do instead. Give the location and the version reference directly — "page 6, version 04" — rather than inviting the reader to compare two long documents and find the change. A recipient who has to diff the files to locate the correction will often not do it, and the one who does may find a different change first.
Keep the notice's weight honest, too, in both directions. Inflate a heading fix into a solemn withdrawal and you spend your credibility; readers learn that your correction notices are loud, and they start skimming them. That skimming is what fails on the day you actually withdraw a promise. Match the notice to the change and the signal stays worth reading.
And keep the notice out of territory it can't hold. A correction informs; it does not establish that the message was read, and it does not create acceptance. Don't write "by continuing, you've confirmed version 04." If a change genuinely needs to be signed off or reflected in a contract, that's a separate track owned by someone other than the person writing the note.
Follow the dependency beyond the first recipient
The first recipient is the start of the trace, not the end of it. Once you know what the error let people believe, ask who else incorporated it — which authorized people or downstream documents now lean on the wrong statement. That is not the same as sending the correction to everyone you can think of. Expanding distribution has its own costs, and it isn't your call to make.
The move is to route the correction through the responsible project owner and let that owner decide who else needs it. And be ready for the two readers who depend on the same sentence in different ways. A director might accept the wording change with a shrug: fine, the sentence about the rooftop is corrected, the sequence she pictured is unchanged. Her "no problem" closes her question and nothing else. A producer who has already built a schedule around "secured" has a different decision in front of him, and that decision doesn't belong to the director. The wording and the consequence have different owners. One person accepting the fix doesn't resolve the other's exposure.
This is the line where a correction stops being copy editing. If the wrong statement touches a contract, a confidentiality expectation, a third party's rights, or a commitment made to a client, it belongs with the relevant owner — legal, the producer, the account lead — rather than getting a tidy "updated, please use v04" note and a hope that it holds. Keep those with the owner instead of editing the treatment quietly and calling it handled. The sentence may be yours to fix; the promise may not be yours to withdraw alone.
Close with a usable current record
A finished correction leaves three things connected: the replacement, the notice, and the affected decision. The current version is version 04. The notice said what moved and why. The unresolved item — rooftop access — is named, with its owner. That is the usable state. Anyone picking up the treatment later can see which version applies and what is still open, without reconstructing the story from a stack of attachments.
Be just as careful about what you don't claim. Sending doesn't establish receipt. You can't guarantee the old copy is gone from every inbox, cache, and forwarded thread, and you don't need to — you need the current version to be unambiguous and the dependency to be visible. "All prior versions are void and inaccessible" is a promise you can't keep and didn't need to make. So is a fabricated deadline: "please confirm by Friday" when no one owns Friday is a small unapproved commitment, of exactly the kind this whole exercise exists to correct.
So confirm the actual next step rather than inventing one. If the access question sits with the producer, say that and stop. If a client needs to hear the change, name who will tell them. Leave the dependency attached to the person who owns it, not dissolved into a tidy file.
The test of a finished correction was never a clean document. It is whether a reader holding the old version can find out what changed, which version now applies, and what — if anything — they need to do about a decision they already made. An edited file is not a correction that reached the people using its predecessor. Get one current version, a notice matched to the change, and any unresolved dependency named with its owner, and the two versions collapse into one.
Frequently asked questions
How do I decide whether an error needs a correction notice or just a quiet file update?
Sort by consequence and reliance, not edit size or embarrassment. Ask what a recipient could reasonably have concluded that is not true, and which subsequent action could rest on that conclusion. A typo that alters no conclusion usually fails both questions; a changed scene, unsupported product statement, or unapproved production promise can commit people and resources and needs a different response.
What version identity should a corrected treatment carry?
Use a replacement that another person can identify without asking—for example, 'version 04 supersedes version 03.' Appending 'FINAL' or 'FINAL_v2' does not tell which file supersedes which. Correct the smallest part that needs correcting, check headings, scene numbers, locations, and repeated claims for references, and keep the old version visible as what was sent; supersede its authority, do not erase its existence.
How detailed should the correction message be?
Match the notice weight to the change. State the location and version reference directly—'page 6, version 04'—and say what to stop believing and what to do instead, rather than making readers diff two long documents. A heading fix can be discharged by opening the page; a location claim requires dropping a belief, working out which actions depended on it, and routing a question to an owner.
Whom should I notify, and who owns the unresolved consequences?
The first recipient is the start of the trace, not the end. Route the correction through the responsible project owner and let that owner decide who else needs it rather than expanding distribution yourself. Different readers may depend on the same sentence differently—a director may accept the wording change while a producer has a schedule built on the old claim—and one person's acceptance does not resolve another's exposure. Contract, confidentiality, third-party rights, or client commitments belong with the relevant owner.
What can a finished correction not claim or guarantee?
Sending does not establish receipt, and you cannot guarantee the old copy is gone from every inbox, cache, or forwarded thread. Avoid promises like 'all prior versions are void and inaccessible' and avoid fabricated deadlines such as 'confirm by Friday' when no one owns Friday. The usable state is one current version, a notice matched to the change, and any unresolved dependency named with its owner.