Receiving / R4 · Cross-format Verification

How to Decide Whether a Handoff Can Move Forward

A handoff should not be accepted merely because its files open. A useful receiving sequence asks three questions in order: can the records be tied back to the media, can they be tied back to scene-shot-take identity, and can the on-set judgment actually be traced in the output that is being used? SlateX can expose the literal values and relationships it writes. Whether those values are sufficient for a downstream workflow remains a receiver-side decision.

Receiving is not a single pass/fail stamp. It is a sequence for eliminating unclear identity, broken record relationships, and untraceable judgment.

First verify that the record can be tied to media

Start with media identity and time position. Reel, clip name, camera, start position, duration, and frame rate need to be traced back to the media or the on-set record. Some values are entered by people, some are derived by the software, and some are fallback strings written when source data is missing. The receiver should identify which kind of value is being read before relying on it for matching.

Syntactic validity is not the same as factual validity. A well-formed timecode string may still be a fallback, and an end position may be calculated from a start value and duration rather than independently observed. When a specific receiving application is involved, the supported boundary is narrower: the receiver should verify the columns against its own import template.

If media identity or the source of a time value cannot be traced, stop at this stage and return to the source record. Adding receiver-side interpretation to an untraceable value only makes its origin harder to explain later.

Then verify scene, shot, and take identity

Once the media can be identified, check whether the record can be connected back through scene, shot, and take identity. The four output forms are not simply alternate views of one identical table, so a row number in one output should not be assumed to identify the same row in another.

A practical review can sample a subset of takes by scene rather than manually reading every row. The point is not to prescribe a numeric sampling rate. It is to cover ordinary records and records with complicating conditions such as multiple cameras or missing values while keeping the manual review bounded.

At this stage it is enough to know that row counts and ordering may differ. The detailed sorting mechanisms belong to a separate explanation. For cross-file matching, use scene, shot, and take identity rather than row position.

Finally verify whether judgment is actually carried

Only after media and record identity have been established should the receiver ask whether on-set judgment is traceable. A column being present and a column representing the full meaning of an on-set status are not the same thing.

The structured list does not contain a rating field, so it cannot recover Circle, Keep, Hold, or N/G judgment by itself. The tabular output contains Rating and Circle, but Circle is written as TRUE only for the take marked Circle; it is not a general representation of every on-set “circled” meaning. The readable report is one row per take and carries only part of the parameters from one camera on that row. The script project file carries script structure rather than shooting results, takes, cameras, or timecode.

The same take appearing in several outputs does not mean each output carries the same judgment information.

What each output can carry through the review

The structured list can be used to inspect per-camera media identity, time values, and scene/take context, but it has no rating column and does not carry a media path or channel map. The tabular output contains more recorded fields and rating text, while still requiring care around derived fields. The readable report is useful for a human-readable take overview, but it is not a complete multicamera parameter record. The script project file exchanges script structure and does not carry shooting results back with it.

The receiving goal is therefore not to make every output mirror every other output cell by cell. It is to confirm that each output performs its own role and that important identity can be traced back to source records.

Stop at the layer that fails

If media identity or time-source provenance fails, stop at the first layer. If media can be identified but scene-shot-take relationships cannot be established, stop at the second. If those two layers pass but the required judgment does not exist in the chosen output, do not invent a conclusion the file does not express.

The current evidence also does not support treating shoot-day aggregation or shoot-day export as a verified capability, so this framework does not assume a day-level summary as an acceptance prerequisite. It evaluates the outputs that are actually generated and the values they actually contain.

Receiving remains receiver work. SlateX can provide inspectable values, derivation relationships, and known boundaries; it does not provide a certificate that a downstream workflow has accepted the files.

FAQ

What should be checked first in a handoff?

Start with media identity and the source of time values. If reel, clip, camera, start, duration, or frame rate cannot be traced to media or an on-set record, later scene/take and judgment checks lack a reliable foundation.

Why not match the outputs by row number?

Because row counts and ordering are not the same across the output forms. Scene, shot, and take identity should be used as the common key instead of assuming a row position carries across files.

Does the Circle column in the tabular output equal the full on-set circled state?

No. The current Circle cell is written as TRUE only when that take is marked Circle, and FALSE otherwise, so it should not be treated as a complete representation of every on-set marked state. The receiver should read it together with Rating and the source record.

Does this process prove downstream acceptance?

No. It defines a receiving sequence and traceability checks. The receiver still has to validate the behavior of its own import environment and downstream process.


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