Set Up a Versioned Review of a TV Pitch Sample

Two cuts of the same pitch sample are circulating. One reviewer has written "the reaction at 0:35 feels wrong." Another has written "the sound drop is abrupt." The third note says the location label covers her hand.

None of those notes is wrong. All three are orphaned. Nobody can tell which cut they were written against, and the newest upload — the one everybody has been told is "the current one" — no longer contains the shot the first note is about.

A review note is usable only when its reader can identify two things: the export it belongs to and the moment inside that export it describes. Everything else in this article is a way of protecting those two facts through the next revision. Set up the workspace so that a note carries its cut and its passage with it, and so that "newest," "viewed" and "approved" stay three different words.

The sample used below is invented for this walkthrough. No footage was uploaded and no review account was opened.

Name the cut before anyone comments on it

The file is easy to describe. The thing the file stands for is harder: the cut you actually want people to look at, standing in for a script that may have moved twice since the assembly was locked.

Write down three things before the export leaves your machine.

The cut name. Something that survives being forwarded into a chat you're not in. pitch-sample_v2_2026-03-09_1m19 tells a stranger the revision, the date and the running time. "Final" tells them nothing, and "final_v3" tells them something untrue.

The source revision. Which script draft, which edit project, which date the sequence was assembled. This is the part that explains why the cut exists — and it's the part that gets lost first, because it lives in a folder nobody outside the edit bay can see.

The review question. "Does the opening land without the voiceover?" produces an answer you can act on. "Thoughts?" produces a rewrite of your series.

Then group the exports so the group keeps its history. The Frame.io V4 versioning documentation read for this article describes a version stack: complete uploads collected together, with the newest version shown first and earlier versions still selectable. The same page describes Version Saves for mounted storage as a separate thing entirely. That distinction is worth keeping straight — a stack of uploads and a source application's version history are not interchangeable explanations of how a project arrived at its current shape, and calling both "versions" invites a confidently wrong story later.

An interface default is not a decision. The stack opening on the newest upload means the newest upload is what a visitor sees first, not that the team has reviewed it. So before you treat anyone's comment as a response to the new cut, check what that person is actually looking at. The documentation says the stack exposes the latest version; whether a particular link still leads where you assumed is a question for the recipient, not an inference from the stack.

Match the anchor to the problem

The commenting documentation describes three ways a note can point at the material: at a timecode, at a range with a start and an end, or at a spot on a frame. Those are the anchors. Choosing among them is a craft decision, not a formatting one.

A single image defect wants a frame. A boom shadow, a label sitting in the wrong place, a look that reads as the wrong emotion — anchor it to one moment and, where it helps, to the place on the picture.

A change across a passage wants a range. If the complaint is about pace, or about how a music cue arrives relative to a line, the note is about the relationship between two moments. Anchor the range across both, so the reader sees the transition rather than one still of it.

A described action is what survives. This is the part that does the real work. A timecode is a coordinate inside a document that is about to be replaced. "The 'CEDAR GROVE — 6:40 AM' label sits over her hand on the deadbolt" is still findable after the cut gets shorter. "Move the thing at 0:08" is not.

Put three notes on one cut

Here is Cut A, a fictional 1:18 sample. Timings are round because a worked example needs them round; your own numbers will be messier, and the method doesn't care.

Three notes go on it.

Note 1 — spatial, on the label at 0:08. "The location label sits over her hand on the deadbolt, so the hand doesn't read. Raise it to the upper right, or delay the label until the hand clears the deadbolt."

Note 2 — range, 0:28–0:33. "The drop from room tone to silence is abrupt — let the tone decay under the piano instead of cutting. And the piano arrives only after Dee's line, so the line lands in silence."

Note 3 — frame, on Mara at 0:35. "She reads as relieved. She has just been caught. Hold on her a beat longer before cutting away."

Compare versions without pretending the notes moved themselves

Cut B is now 1:19. Three things changed.

• A four-second cold open was inserted at the head: a car pulling into the empty lot.
• Mara's reaction shot, 0:35–0:38 in Cut A, was removed.
• The piano entry was pulled one second earlier than the head insertion alone would have placed it.

The arithmetic is worth doing once, because it shows you what arithmetic can and can't tell you. The head insertion adds four seconds to everything after it. The removal subtracts three seconds from everything after that. So material that sits after the deletion lands one second later in Cut B than in Cut A.

Now read the old notes against the old cut, and only then go looking in the new one. Each note ends up in one of four places.

Still relevant. Note 1 is the easy case, and it still has to be checked rather than assumed. The label is still at 0:12, still lower-left, still over the hand. The spatial anchor held because the label itself survived the re-edit — but you only know that because you opened the revised frame instead of trusting the math.

Still relevant, partly. Note 2 has two complaints and they diverged. The abrupt drop-out is untouched: it still cuts instead of decaying. The second complaint — the piano arriving after Dee's line — is now moot, because the cue was pulled forward and the line no longer lands in silence. The note stays open on its first half. Two-part notes are normal; record which half is live, or the next person will re-litigate the whole thing.

Superseded by a different edit. Note 3 is the one that matters. The shot it was anchored to does not exist in Cut B. That does not mean the note was addressed. If anything, the concern — Mara reading as relieved rather than caught — is now unaddressed and harder, because there is no reaction at all after the line. Either the removal was the director's answer to the note, or the removal was a trim and the problem is still sitting there. That is a decision for a person, not for the interface.

Needs clarification. Reserve this for notes you genuinely can't place — a comment whose described action you can't find in either cut, or one that contradicts another note. Don't use it as a polite way to avoid deciding.

What you should not expect is automatic comment remapping. The commenting documentation establishes that a note can reference a timecode, a range or a spatial location. It does not establish that those anchors follow the material into a differently edited version. So plan as though they don't, and be pleasantly surprised in your own workspace if they do. The removal in Cut B is exactly the situation where no mapping rule could help anyway: the anchor's target is gone, and no amount of tracking reconstructs an intention.

One more piece of housekeeping. Don't reset the history by uploading the old cut again under a new name to re-collect comments. You'll end up with a stack whose newest entry is older material, which is the version-management equivalent of writing over yesterday's file.

Keep the decision separate from the conversation

The thread is where the argument lives. The decision needs somewhere else to live, because a thread is inside one account and a pitch goes to people outside it.

Give each consequential decision one line in a portable record:

Three properties make that record worth keeping. It names the export, so the decision can't drift onto a later cut by accident. It names a person, so "we decided" has a referent. And it survives being pasted into an email to someone who will never open your review workspace.

When two notes ask for incompatible edits — one reviewer wants the cold open to start colder, another wants it shorter — resolve it in the record rather than combining both into something nobody asked for. When a note is declined, write one sentence about why, close enough to the note that the reasoning travels with it. A declined note with no context gets re-raised in three weeks with more confidence than it had the first time.

And keep the three states separate in your own head. Newest is what the stack opens on. Viewed is what a specific person has actually watched. Approved is a creative decision someone made and is willing to be named for. Nothing in a review interface converts the first two into the third, and a completed checkmark is a person closing a note, not a network buying a show.

End with one export and a short list

The point of all this is a review history you can navigate, not a tidier folder. So finish the pass by naming the artifact under discussion — pitch-sample_v2_2026-03-09_1m19 — and writing the unresolved list underneath it:

• Label over the hand on the deadbolt at 0:12. Open.
• Room tone still cuts at 0:32 instead of decaying under the piano. Open.
• No reaction after "Then sell it." Was the removal the answer, or is the beat still missing? Needs a decision.

That is a complete review state. It doesn't resolve the notes, and it shouldn't: the third item needs a person, and a person needs to see the same cut everyone else saw. What it does is make the next round cheap. When the next export arrives, each note has a described action to hunt for, a version it belonged to, and a decision trail that explains why the cut looks the way it does.

A comment that can't name its cut isn't feedback. It's a memory, and memories are the most expensive thing to argue with.

Frequently asked questions

What must a review note identify to remain usable?

A review note is usable only when its reader can identify the export it belongs to and the moment inside that export it describes. Otherwise the note is orphaned, and the newest upload may no longer contain the shot it was about.

What should be recorded before an export leaves the machine?

Write down a cut name that survives forwarding, such as one carrying revision, date and running time; the source revision, meaning the script draft, edit project and assembly date; and the review question, such as whether the opening lands without voiceover. Group exports so the group keeps its history, and keep a stack of uploads distinct from a source application's version history.

How should a comment anchor be chosen?

A single image defect wants a frame or spatial anchor, while a change across a passage wants a range with a start and end so the reader sees the transition. A timecode is a coordinate inside a document that is about to be replaced, so a described action, such as a label sitting over her hand on the deadbolt, survives re-editing better. Do not expect automatic comment remapping: the documentation establishes that a note can reference a timecode, range or spatial location, not that those anchors follow material into a differently edited version.

How should old notes be handled when a new cut changes material?

Read the old notes against the old cut first, then inspect the new one. Classify each note as still relevant, still relevant partly, superseded by a different edit, or needs clarification. For example, a label note may still hold only after checking the revised frame; a two-part sound note may have one half moot; and a note anchored to a removed reaction shot is superseded, not addressed, so its concern may remain and need a person's decision.

How should decisions be kept separate from the conversation?

Give each consequential decision one line in a portable record naming the export, decision, owner and date. Resolve incompatible notes in that record rather than combining both into something nobody asked for, and when a note is declined, write one sentence about why close to the note. Keep newest, viewed and approved separate: newest is what the stack opens on, viewed is what a specific person actually watched, and approved is a creative decision someone is willing to be named for.

Further reading

• Update a Pitch From a Revised Script When the Production Page Numbers Are Locked — When you need vocabulary for anchors that must survive revision, this shows how locked page numbers stay identities even as omissions and insertions mount up.