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 assets stay 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 assets are 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 come out in the same row order in every output. All three expand by camera now, so row counts sit at one granularity within a single export; what differs is the sort — the tabular file largely keeps creation order, the structured list re-sorts by scene, shot number and take, and the readable report sorts by scene, shot name and take. A row number is therefore not a cross-file identity. Receivers should align records by scene, shot, and take instead.

Continuity assets need 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 and some are derived during generation; the receiver should check each column by its source.

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. For the receiving order across those artifacts, see “How to Decide Whether a Handoff Can Move Forward”.

Multicamera records make this especially visible. When a take has several cameras, the structured list, the tabular file and the readable report all expand into one row per camera, and each row carries only that camera’s own readings. The report’s table has no camera-number column and lists fewer fields than the machine-readable files, so the full set of one camera’s parameters is 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 assets, 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 each output sorts the same records by its own keys: the tabular file largely keeps creation order, the structured list re-sorts by scene number, shot number and take, and the readable report sorts by scene, shot name and take. All three expand by camera now, so row counts sit at one granularity while row positions still do not correspond. Alignment should use scene, shot and take identity, and on a multicamera row the camera as well.

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

One row carries one camera’s own readings. Each camera gets its own row within the same report, but the table has no camera-number column and lists fewer fields than the machine-readable files, so parameters that never made it onto this table still belong to the ALE or the CSV.

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