What a Script Supervisor Needs to Hand Off at Wrap

At wrap, a script supervisor is not handing over “one table.” The handoff is a set of records that lets the next reader reconstruct what happened on set: take records identify the scene, shot, take, rating, and notes; continuity evidence stays tied to the relevant record; timecode context lets a receiver check time position; and the delivery set tells the receiver what files were actually supplied. SlateX can project the same recorded material into several exchange forms, but it does not replace the receiver's job of verifying those values.

A wrap handoff works when the next reader can still get back to the same scene, shot, and take—not merely when a file has been generated.

Separate the production task from the software output

The production task is to leave behind enough identity, judgment, and continuity context for downstream work. Take records are read by people who need to identify material and understand what was recorded. Continuity evidence is read by people who need to revisit visual or physical continuity. Timecode context is used when written records are checked against media time positions. A delivery set tells the receiver which artifacts are present and which questions still require a source record.

SlateX output is a software representation of that task, not the task itself. The current product can produce a structured list, a tabular file, a readable report, and a script project file. Those outputs turn existing records into different exchange forms. They do not remove the human step of deciding whether the records agree with the media and the receiving workflow.

That distinction matters: the script supervisor is responsible for leaving traceable information; software is responsible for expressing recorded data. One should not be described as replacing the other.

Take records need an identity that survives the handoff

The common key is scene, shot, and take. Rating and notes preserve the judgment or explanation recorded on set, but identity is what lets a receiver align different artifacts again.

This matters because the same take records do not have identical row counts or row order in every output. Camera-expanded artifacts can turn one take into several rows, while the readable report keeps one row per take. The outputs also apply different ordering rules. A row number is therefore not a cross-file identity. Receivers should align records by scene, shot, and take instead.

Continuity evidence needs context, not just a folder of media

A continuity photo becomes useful in a handoff when its relationship to the recorded take, shot, or continuity object remains available. The downstream reader needs to know what the evidence was attached to rather than receiving an unstructured pile of images.

That relationship does not mean the software has made the continuity judgment. Being able to associate and review evidence is different from deciding whether wardrobe, props, performance, or visual action truly match. The handoff should preserve the traceable relationship and leave the judgment to the person reviewing it.

Timecode context needs a verification path

Time position gives written records a way to be checked against media. A receiver should not accept a value merely because it looks like valid timecode. Some exported values come from the recorded data, some are derived during generation, and some missing inputs can produce fallback-looking values.

The handoff therefore needs more than a timecode string. It needs the identity of the record and a clear path back to the source that can confirm it. Whether a downstream system can use a field directly is for the receiver to determine by checking the columns against its own workflow.

One set of records becomes several different artifacts

SlateX's four current exchange forms serve different reading tasks. A structured list and a tabular file expose fields. A readable report is arranged for human review. A script project file returns to script structure. They are not four row-for-row copies of the same document.

Multicamera records make this especially visible. A single take with several cameras expands into several rows in the camera-oriented outputs. The readable report remains one row per take, and that row contains camera parameters from only one camera. The full set of multicamera parameters is therefore not present in a single report row.

A delivery set is a group of related views of the record, not a group of files that can be joined by row number.

A handoff record is not a handover feature

SlateX currently has no implemented “handover,” “shift change,” or simultaneous multi-person editing workflow. Moving the work to another device requires the next person to select the working position again; there is no product state that should be described as “handover complete.”

This article can therefore say what information must remain in the record: scene, shot, and take identity; recorded judgment and notes; continuity relationships; time position; and the contents of the delivery set. It cannot turn the existence of those records into a claim of seamless shift handoff or multi-user collaboration.

The contents of a single take record are a separate question

This parent topic stops at the information families that must survive wrap and why downstream readers need them. The already published page “What a Take Record Needs for Handoff” handles the narrower question of what belongs inside one take record. That field-level question should remain separate from the question of how a full handoff is assembled.

FAQ

Is a wrap handoff just one exported table?

No. Take records, continuity evidence, timecode context, and the delivery set serve different purposes, and SlateX exposes recorded data in several different forms rather than one all-purpose file.

Why can I not align the exported files by row number?

Because the outputs expand and sort the same records differently. Multicamera takes can become several rows in some artifacts while remaining one row in the readable report, so alignment should use scene, shot, and take identity.

Does the readable report show every camera parameter for a multicamera take?

No. The current report keeps one row per take and takes its camera parameters from only one camera, so all multicamera details are not present in that single row.

Does SlateX provide a shift-handover or simultaneous multi-user editing workflow?

No such workflow is currently implemented. The records can preserve information for the next person, but that should not be presented as a product handover or collaboration feature.

Axiom One LLC — SlateX. Figures current as of 24 September 2026.