Chapter 31 · Handing over

Yasser Ashour

12 minutes ago

12 min read

Part 6 · Edit, finish and delivery

A film is not delivered when it plays. It is delivered when someone else can open it, change it and render it again: an editor next month, a client who was promised an editable project, you yourself after a revision round. This chapter teaches what to hand over, how to lay it out and label it, how a cut planned by an assistant reaches Premiere, and how to prove on a copy that the handover does what it promises.

In this chapter

What a handover contains, and why a project that opens is not yet an editable handover
One folder layout, file names that survive a move, and the two slates
The routes into Premiere: which formats carry what
Building a handoff from the edit plan, and verifying it on a copy

Before you start. Chapter 29 teaches the edit plan and the cut; Chapter 30 finishes it; Chapter 32 is the Premiere Pro section; the run record (8.7), whose origin labels travel into the delivery, is kept on the platform in Chapter 33.

31.1 What a handover is for

On a shoot, the edit ends in a project another editor can open, with the knowledge that the timeline will behave. An AI production has to earn the same thing, because much of its cut is reasoned by an assistant and written to a file by a program, not built by hand in the editing application. The handover is where that work is proved or quietly abandoned. You need a real one whenever the cut must outlive your own Premiere session. Below, the handoff is the timeline file and the checks that prove it (31.5), one part of the handover.

Deliver the native project, the collected media and a reference render, and add an interchange file only for a destination that has been tested. No verified universal project or XML preserves every effect, graphic, font, grade and audio edit across Premiere, Resolve and CapCut. An interchange file describes a cut; it is not a project. What it cannot carry stays in the native project or is rendered as replacement media with a note.

The handover contains:

the native project, saved by Premiere on a recorded build, with a sequence for each version;
the collected media: every file the project uses, gathered so that the package can travel (File > Project Manager);
separate stems (dialogue, effects, beds, music), and the sources of every graphic, title and caption with their fonts (30.7, 30.9);
a reference render of the same version, so that the next editor can see what the timeline should produce;
the file manifest (manifest.json): for every file its path, duration, frame size, frame rate, streams, checksum (a fingerprint of its contents) and the interval the cut uses, with its origin label: generated, upscaled, painted over, composited, practical, client-supplied or stock (the run record, 8.7);
the editability table (31.5), and a statement of what was and was not verified, on which build.

Origin labels are how a lawyer, a platform or the next editor finds out which frames were generated; with the hash, they make every clip traceable to its source and route, so that a later replacement is a swap and not a rebuild (Chapter 34 covers what permission does and does not establish).

A project that opens is not an editable handover. It becomes one only when the revisions it promises (replace a take, shorten a clip, lower the music, retype a title) have been performed on a copy, saved, reopened and rendered. Parsing is not delivery: never report an XML file as validated merely because it parses.

Who does what. The assistant writes the plan, has a program write the timeline file, validates it and records the results. The director, or an editor working for the director, opens it in Premiere on the Mac, performs the checks and signs. An assistant that cannot reach that Mac cannot confirm what Premiere did, so a Premiere step the assistant could not run is reported as "implemented", never as "executed". Release is a separate authority: a package that passes every check is delivery-ready, pending the director's release acceptance, the acceptance gate (8.1).

31.2 The folder, the names and the slates

Build every edit folder the same way, so that you, the assistant and the next editor know where everything is, and a checklist can point at a folder by name. The layout is a template, not a law.

Template: the edit folder (written for this book; not run)

<Mac>/Projects/<YYYY>_<client>_<project>/10_edit/
  <SEQ>.xml  <SEQ>.otio  manifest.json  RELINK_NOTE.txt  edit_plan.json
  media/            flat, ASCII names: clips, keyframe PNGs, locked voice takes, bed, Foley, music, cards
  01_Sources/       Video/{Generated, Upscaled, Practical}  Audio/{VO_LOCK, BED, FOLEY, MUSIC, STEMS}  Graphics/{Cards, Fonts}
  02_Sequences/     Seq_16x9_v<N>  Seq_9x16_v<N>  (one per deliverable format; each cutdown its own)
  03_Finishing/     Grade/  Captions/{ar, en}  Upscale/
  04_Exports/       00_MASTERS/  01_REVIEW/  02_DRAFTS/
  verification/     the screenshots of each step of the check

The edit plan is the source of truth. The timeline files are written from it and never edited by hand: a change is made in the plan and the files are written again.
The media folder is flat and every name is plain ASCII. The timeline file stores each file's full path; when the folder moves you locate one file and let Premiere relink the others. Arabic belongs in markers, clip names and titles, never in a file name (8.9).
One sequence per deliverable format, and each cutdown its own, so that a change to the long version never silently changes the short one (30.8).
An upscaled copy sits beside its native original and never replaces it. Exports are sorted by purpose: delivery masters, review copies, drafts. The verification folder holds the screenshots of the check in 31.5; without them the next person takes the check on trust.

Name every file so that it says what it is and which version it is. 8.9 gives the pattern: project, shot, what it is, version (HIB30_S03_clip_v02.mp4). Add a prefix for the kind of asset (VO_, MUS_, SFX_) and name sequences by format (Seq_16x9_v03). A review note that says "the pour shot" is ambiguous; one that says HIB30_S03_clip_v02 is not. Give every track one purpose. The audio lanes are those of 29.2. For picture, put the main generated shots lowest, cutaways above them, overlays and graphics above those, and titles, end slates and adjustment layers on top, so that each layer switches off on its own. Logos and supers get their own tracks, so that a late change of tagline is a retype (30.9).

The slates

A generated film is reviewed many times before it is finished, and every review copy looks finished. The slate stops a draft from being judged as final. There are two labels, and every export carries its version.

Slate	When
DRAFT — NOT FOR APPROVAL	work in progress: nothing is asked of the viewer; any test cut or test of a route (an import, an upscale, a render)
ROUGH CUT vN — FOR EDIT DECISION: [the question]	a cut sent because a decision is wanted; it names the question

Burn the slate into the picture where a crop cannot remove it, and repeat the version in the file name.

Template: the two slates (written for this book; not run)

DRAFT — NOT FOR APPROVAL · v04
ROUGH CUT v3 — FOR EDIT DECISION: does the pour or the pack shot open the film?

31.3 Delivery masters and packages

The delivery contract decides every value of a delivery master, the high-quality file each encode is made from (a file, not the master of 10.2, which is a picture): codec, container, profile and level, resolution, frame rate, scan, bit depth and chroma, colour tags and range, audio codec, layout and sample rate, loudness, captions and naming (8.2). ProRes is a codec family and not one delivery setting: the profile, chroma, bit depth and alpha come from the contract. If the contract is silent, ask for it in writing. Before export, check levels on the scopes, subtitles (burned in only if the delivery asks), sync, and, on a vertical version, the safe zone. Loudness is measured against the named specification, never typed (30.6).

Mastering a deliverable

Probe the originals, and choose the native original or an approved upscale by need and by test (30.3).
Render the delivery master, a mezzanine file, from the managed sources, through the documented output transform.
Encode each deliverable from the delivery master; reopen and probe each output, and compare duration, frame count and sync with it.
Review the whole file end to end, validate the metadata, sidecars and naming, then hash, package and archive, keeping the previous delivery masters.

A package that fails its final check is rejected, not patched: a repair made on the encode leaves the sources and the delivery out of step.

Research exemplar · editorial · a package that fails quality control · written in the July 2026 research, never run

Example 31.1 — a delivery rejected and rebuilt

Reject delivery; return to approved picture/audio/caption sources; correct caption encoding/shaping and audio mapping; re-encode; probe and watch the complete file again; issue a new checksum/version.

The work returns to the approved picture, audio and caption sources; nothing is patched on the encode.
Both faults are named (caption encoding and shaping, audio mapping), and the whole file is watched again.
A new checksum and version keep the corrected package from being mistaken for the failed one.

31.4 The routes into Premiere

A cut planned by an assistant reaches Premiere in one of three ways: as a timeline file Premiere imports, through its scripting interface, or rebuilt by hand. Premiere 26.5, released on 10 Sep 2026, is the current release (checked 30 Sep 2026); its release post mentions no change to interchange or scripting (read 29 Sep 2026).

Route	What it carries or does	Use it as
Final Cut Pro 7 XML (xmeml), imported with File > Import	In a round trip on a Premiere 27 beta (12 Sep 2026), cuts, a dissolve, fades, audio-level keyframes, ripple trims and Arabic markers arrived. Adobe warns that pan, gain, level, complex effects and transitions may not translate (page updated 7 Jan 2026).	the route into Premiere; check every new build
FCPXML (Final Cut Pro 10 and later)	A different format. Adobe has said it needs conversion before Premiere can import it (page updated 2 Apr 2026; current wording unconfirmed). Renaming the extension converts nothing.	not a route until tested
OTIO (OpenTimelineIO); EDL, AAF	OTIO is a JSON tree of the timeline; adapters keep what the core format lacks as metadata; no instancing. EDL and AAF are older formats.	a readable record of the plan; qualify each by test before promising
Scripting (UXP)	Adobe's documentation (last read 28 Sep 2026) describes inserting, overwriting, cloning and removing clips in transactions (Premiere 25.6 and later); it needs Developer mode, which only the person at the Mac can switch on.	a possible future route; not tried on a handoff
A project file written outside Premiere	Nothing reliable.	never

The three formats are three formats, not one, and a file is its format, not its name. Target one destination.

Know the timing fields. In the older Final Cut XML in and out are source times, start and end are sequence times, and end = start + (out − in) is the first check of any exporter (29.2).

Import the XML with File > Import. On the 12 Sep beta, Open Project refused an .xml file. Expect a bin with the sequence and its media and nothing offline. Read the translation log whenever Premiere exports XML: its report, "FCP Translation Results", lists what did not carry.

Two behaviours to check on any new build (32.2): keyframe times and clip-marker positions are counted in the source clip's frames, so an exporter that writes them in sequence time misplaces a fade or a marker; and at a transition Premiere's own XML carries −1 as the start or end of the touching clips, a convention and not drift.

A Premiere project file is saved by Premiere, never generated. The assistant delivers a timeline file, the media and the paperwork; Premiere builds and saves the project; the director checks it. Record the build: a handover that works on one build is not proved on another.

A generation with several shots inside it (13.5) reaches the edit as one file. Split it with Scene Edit Detection (32.2), and treat each detected boundary as a place to look, not an editorial decision.

Other destinations (Resolve, CapCut, Final Cut) are qualified as a Premiere handoff is: build, open, revise, reopen and render in the destination itself, because a rendered file proves playback only. No supported route from XML into CapCut has been shown: deliver a reconstruction package (master, media, stems, edit decisions), labelled as such.

31.5 Building and verifying a handoff

Inputs. A frozen inventory: every file with its path, duration, frame size, frame rate, streams, checksum and accepted intervals, missing files resolved first; the edit plan (29.2); separate stems and the sources of every title. Tools: Premiere on the Mac, its build recorded; the exporter, the program that writes the timeline file from the plan; the assistant for the plan and the checks.

Figure 31.1 — The handoff chain. The top row can be done anywhere and proves only that the file is well made; the bottom row needs the Mac and proves that the film is what the plan says.

Building the Premiere handoff

Freeze the inventory; resolve missing files first.
Write the plan explicitly, dialogue, music and effects on separate tracks.
Build for one declared destination: for Premiere, Final Cut Pro 7 XML.
Validate before anything reaches Premiere: every file exists; every range sits inside its source; durations add up; frame rates are exact; paths are encoded; text is escaped (ampersands and angle brackets written so the XML stays readable).
Import a short sequence with overlapping dialogue and music, and check it yourself.
Build natively what the exporter does not carry: overlaps (J and L cuts), titles, graphics, speed changes, the grade, the mix automation, keeping their editable sources.
Save, close, reopen and relink; render the delivered project and compare the render with the plan.
Export an XML for another editor only when needed, and read its translation log.

Let the assistant choose the ranges and a deterministic program write the XML: XML written freehand in a chat fails on structure. Every check in step 4 needs neither the Mac nor a credit. Test sound with sound: a silent, single-track test proves nothing about audio. Build overlaps natively until a J or L cut has been imported and heard, and never offset dialogue to simulate an overlap while the speaker is visible. The render is the proof: a draft render and the XML read the same plan, but that does not prove they interpret it the same way.

Verifying a handoff, on a copy

Verify before any handoff leaves you: a new build or a new kind of clip or title can break a route that worked. Test exactly what the handoff promises, on a copy; testing the original risks the delivery.

Figure 31.2 — Five levels of proof. Each level proves something the one below cannot; only the fifth proves delivery.

Template: the handoff and its verification (written for this book; not run)

Build the Premiere handoff for [sequence] from [inventory] and [edit plan]. Keep every accepted range. Before substituting anything, report missing files, rate mismatches and operations the exporter cannot carry. Validate the ranges, then list the native finishing operations. After import on the Mac, on a copy: check the sequence settings and every link, perform [each promised revision], save, close, reopen and render; compare with [reference render]. Move the package and relink; count manual locates. Report each step as executed or implemented, and which items remain baked. Do not describe successful XML parsing as successful film delivery.

Fill the editability table from results, never from intent. Every item goes into one of three classes: native-editable (it can be changed as an edit); baked with its source kept (it plays as pixels or a mix, and the file to rebuild it travels with it); or not carried. A table written before the test is a plan for a test, not a description of the handover.

Template: the editability table (written for this book; not run)

Item	Class, from the result	Evidence
Cuts, trims, track layout	[native-editable / baked, source kept / not carried]	[step, build, date]
Keyframes; cross-dissolves; speed changes	[ ]	[ ]
Title cards (PNG with alpha); captions	[ ]	[ ]
Grade, LUT, effects	[ ]	[ ]

Inspect the first, middle and last frame of each placement, every cut, the full audio, the duration within one frame and the measured loudness. A cut can survive an import with its first frame right and its last one out; only the three frames together show it. If a step fails, diagnose it, rebuild, and repeat the whole check, not the failed step alone. In the 12 Sep round trip one take's audio–video link changed on save; a route that does that once may do it again on a client's project. Record it as a finding, and find its cause before trusting the route again.

Before a handoff leaves you

The native project was saved by Premiere, on a recorded build; the media is collected, flat and ASCII-named, with a checksum for each file.
Stems, title sources and a reference render of the same version are in the package.
Every promised revision was performed on a copy, saved, reopened and rendered; the package was moved and relinked, manual locates counted.
The editability table was filled from results; no "expected" is left.
Every export carries its slate and version; delivery masters are in their own folder, reopened and probed; every asset carries its origin label.
An interchange file is included only for a destination that has been tested.

Open questions

FCPXML into Premiere 26.5. Adobe updated its page on 2 Apr 2026; test a small file before promising it.
Premiere's scripting interface, J and L cuts, constant speed changes, a native Arabic text layer, OTIO, EDL and AAF. None is shown to survive a handoff; build natively, and test before relying.

What to remember

Deliver the native project saved by Premiere, the collected media, stems, title sources and a reference render; add an interchange file only for a destination you have tested. A project that opens is not an editable handover; parsing is not delivery.
Every project gets the same folder; media is flat and ASCII-named; the Arabic lives in markers and titles.
Two slates and a version: "DRAFT — NOT FOR APPROVAL" for work in progress, "ROUGH CUT vN — FOR EDIT DECISION: [the question]" when a decision is wanted. Every export carries its version.
Every value of a delivery master follows the named delivery contract. Reopen, probe and hash every output; a package that fails is rejected, not patched.
Final Cut Pro 7 XML, FCPXML and OTIO are different formats: target one destination, import with File > Import, and never generate a project file outside Premiere.
Validate offline, import a passage with dialogue and music, build overlaps and titles natively, then save, reopen, relink, render and compare. A step the assistant could not run on the Mac is "implemented", never "executed". Release is the director's separate acceptance.