What a Take Record Needs for Handoff

A take record is useful for handoff when the next person can answer a short set of practical questions: which shot and take is this, what did each camera record, what status was assigned on set, where does the take begin in time, what exception needs a note, and where is the related continuity evidence. In SlateX, the current record path covers the take number, camera collection, status, start timecode and duration, take notes, and continuity-media binding. With multiple cameras, each camera keeps its own parameter set.

A handoff-ready take record is not a pile of fields; it is a traceable path from “which take” to “which camera, what status, what time, and what evidence.”

Start by making the take identifiable

Identity comes first. A take number needs the shot it belongs to, otherwise “take three” has no stable context once the record leaves the person who created it. SlateX associates the take with its shot and carries the take number through the record flow. When reading a take record, treat shot context and take number as one identity pair rather than reading the take number in isolation.

The record also needs camera-specific information that can distinguish the media captured for that take. With multiple cameras, SlateX does not reduce them to one shared camera description. Each camera has its own parameter group. For handoff, camera ID, reel, clip number, and frame rate are the first identity cues a receiver can check; the on-set record can also carry lens, aperture, focus distance, color temperature, sound roll, and camera notes. The point is not to advertise a field count. The point is to keep each camera's identity separate.

Reel and clip information should stay attached to the camera

When one take has several cameras, reel and clip information should be checked per camera. SlateX snapshots the current camera collection when a new take is created, and a newly added camera starts from inherited camera parameters that can then be changed on set. That only describes how parameters carry over; no time-saving, error-reduction or context-loss effect has been measured here. A receiver should still read each camera's reel, clip number, and other parameters as its own record.

Those camera-level values also feed later camera-specific handoff output, which is another reason to keep them distinct at the take-record stage. There is a known boundary around the current reel and clip naming source, so this article treats those fields only as “what is currently recorded for this camera.” It does not present a naming pattern as something already accepted by a downstream receiving workflow.

Record the on-set status, but do not describe Circle as globally exclusive

SlateX uses the on-set status labels Circle, Keep, Hold, and N/G. Their handoff job is straightforward: the next person can see how the take was judged on set without having to infer that judgment from a free-text note. Status belongs in the take record, but it is not maintained as a global invariant through every editing entry point.

At present, only the take-log panel performs the automatic change that turns other Circle takes in the same shot into Keep when one take is set to Circle. Changing status from the create or edit screens bypasses that step. As a result, one shot can still contain two Circle takes. Describe the behavior narrowly as an automatic change in the take-log panel, not as a guarantee that a shot can never contain more than one Circle.

One more boundary belongs in the handoff: the rating is visible differently in each delivered file, so neither “it always travels” nor “it never travels” is correct. The 19 ALE columns carry no rating or circle column at all. CSV has an English rating enum (Circle / Keep / Hold / N/G, not localized), but it also has a Circle boolean column that writes TRUE only for Circle — so a take marked Keep reads back as FALSE there. PDF has a rating column in its 12-column header, drawn as a colored dot plus English text. A receiver should therefore read the rating per file and per column, and not infer from “what was marked in the app” that “the same mark must appear in the exchange file”.

Status records an on-set judgment, but the current flow does not guarantee that every editing entry point preserves a single Circle per shot.

Timing should locate the take, not just produce a precise-looking string

A handoff-ready take needs a time position. The current interface can record a start timecode and a duration, and the start can be populated from the current timecode when the take is created. These values answer “where did this take start?” and “how long did it run?” They should be read together with the shot, take number, and camera context instead of being treated as an isolated time string.

The boundary matters here: a take-record checklist should only include time fields that the interface can actually capture. A column existing in the data model is not enough. If there is no on-set input path for it, it should not be promoted into the handoff list. That keeps the article aligned with what a person can really record rather than what a schema happens to contain.

Use notes for exceptions and continuity media for evidence

Structured fields can identify the take, camera, status, and timing, but on-set exceptions do not always fit an enum or number. The take note is the place for specific context that the structured fields do not express. A useful note should add the missing fact, not repeat the take number or reel that is already stored elsewhere.

Continuity media serves a different role. It is evidence rather than prose. SlateX can bind continuity media to the take, allowing the next person to return from the record to the relevant photo or video instead of searching an unstructured album without take context. The image does not decide which continuity state is correct; the take record's job is to keep the evidence attached to the production event it came from.

A practical order for checking a take record

Start with shot and take identity. Then inspect each camera separately for camera ID, reel, clip number, and the camera information needed for the handoff. Next read the Circle, Keep, Hold, or N/G status. After that, verify the start timecode and duration. Finish with the take note and continuity-media binding to make sure exceptions and evidence remain attached to the take.

What we cannot do today is treat every column in the data model as an on-set input field. This checklist includes only information that the current interface can capture or that the current record flow supplies. Columns with no input path stay outside it. This is also not a universal industry take-record template; it is a narrow description of what the current SlateX take record can hand to the next person.

FAQ

What should be checked first when handing off a take record?

Start with the shot and take number, then inspect each camera's camera ID, reel, and clip number, followed by the Circle, Keep, Hold, or N/G status, start timecode and duration, take note, and continuity-media binding.

Should several cameras in one take share one reel and clip value?

Each camera has its own parameter group; when one take contains several cameras, check reel, clip number, and other camera information separately for each camera instead of collapsing them into one shared value.

Does one shot always keep only one Circle?

In the take-log panel, setting a take to Circle changes other Circle takes in the same shot to Keep; the create and edit screens do not perform that step, so one shot can still end up with two Circle takes.

What jobs do timecode and notes perform in a take record?

The start timecode and duration locate the take in time, while the take note carries an on-set exception that structured fields do not express; both should be read with the shot, take number, and camera context.

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