Why the Same Takes Do Not Line Up Row-for-Row Across Handoff Files

The handoff files put the same takes in different row positions even though they cover the same records. Each output applies its own ordering keys. The tabular output largely follows the order in which records were created, the structured list re-sorts by scene number, shot number, and take, and the readable report uses a different shot key. All three expand rows per camera now, so within one export their data rows sit at the same granularity; what does not line up is the order.

The stable cross-file key is scene-shot-take identity, not “row number.”

The records are the same, but ordering diverges

The tabular output largely follows the order in which records were created. The structured list reorders the same records by scene number, shot number, and take number, with natural ordering for the first two keys. The take records are the same, but row position is no longer shared.

The readable report has another ordering rule. After scene, it uses the qualified shot name as its second key and then the take number. That shot key is not the same string used by the structured list, so there is no reason to expect row two in one file to correspond to row two in the other.

The on-screen log has yet another order: shot number as a string, then take number. With string ordering, 10 sorts before 2. That is a view-level ordering behavior and should not be used to infer export row positions.

Row positions diverge because each file sorts by its own keys

All three expand per camera: a take with several cameras becomes several rows in each of them, and a take with no camera still receives one row. Within a single export the three files therefore hold the same number of data rows — what differs is how those rows are ordered.

The same rows come out in a different sequence: creation order in the tabular file, scene number then shot number then take in the structured list, and scene, shot name and take in the report. The report’s No. field is also a document row number rather than a take number, so it should not be used as a cross-file identity key.

Different row positions reflect different sort keys; they do not, by themselves, mean that one output contains an extra or missing shoot event.

Shot labels can differ across outputs too

The readable report uses a qualified shot name, while the tabular output uses the underlying shot number. A shot can therefore appear with a fuller label in one output and a shorter identifier in another. The receiver should interpret these values within scene-shot-take relationships rather than rely on exact string equality in one isolated column.

This page describes only what SlateX outputs. It does not establish that a particular downstream application will mismatch, reject, or misinterpret the rows. A receiver should verify that behavior against its own import template.

What to use when reconciling files

Start with scene identity, then shot identity, then take number; for multicamera records, continue with camera identity. That keeps the comparison tied to the record relationship rather than an incidental row position in one file.

Within one export the three files hold the same number of data rows, so when order differs, check which sort keys each file used. Row counts only diverge across scopes: the shoot-day path is the one that writes a report, while the whole-production path writes the ALE and the CSV. Only when the identity relationship itself fails should the review return to the source record instead of demanding row-for-row alignment. When you need to decide whether a handoff can move forward, use the check order in How to Decide Whether a Handoff Can Move Forward.

These differences come from the different roles of the outputs, but that does not remove the need for verification. Each output serves a different role, and the receiver still needs to confirm that the fields being used trace back to the same on-set record.

FAQ

Why do the tabular output and structured list sort differently?

The tabular output keeps creation-time order, while the structured list re-sorts by scene, shot, and take. They cover the same takes but apply different ordering afterward.

Do the files from one export hold the same number of rows?

They do. All three write one row per camera, so a multicamera take takes the same number of rows in each of them, and only the order differs. A report compared against a whole-production export is not a like-for-like case, since that path writes no report at all.

Can the report’s No. column be matched to another file’s row number?

It should not be. No. is the report’s document row number, not the take number, so it is not a cross-file identity key.

What should be used as the common key across handoff files?

Use scene, shot, and take identity, and add camera identity for multicamera records. Do not use row number or row position as the shared key.

Axiom One LLC — SlateX