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

The handoff files can contain different row counts and ordering even though they begin from the same take snapshot. After that common snapshot is captured in creation-time order, each output applies its own ordering keys and row granularity. The tabular output keeps creation order, the structured list re-sorts by scene, shot, and take, and the readable report uses a different shot key. At the same time, the first two expand rows per camera while the report remains one row per take.

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

The starting snapshot is shared, but ordering diverges

The source snapshot is initially collected in ascending creation time. The tabular output does not apply another sort, so it largely preserves that order. The structured list reorders the same records by scene number, shot number, and take number, with natural ordering for the first two keys. The source data is shared, 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 counts diverge when outputs expand per camera

The structured list and tabular output expand per camera. A take with several cameras becomes several rows, while a take with no camera still receives a row. The readable report is different: it is one row per take, so a multicamera take still occupies only one row.

That is the main reason the same record set can produce different total row counts. A multicamera take is split in the list and table but remains one 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 counts reflect different output granularity; 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 SlateX’s output-side mechanism only. 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.

If total row counts differ, first ask whether the outputs use different row granularity. If order differs, inspect whether they use different shot sort keys. Only when the identity relationship itself fails should the review return to the source record instead of demanding row-for-row alignment.

These differences are generated by the output mechanisms, 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 start from the same snapshot but apply different ordering afterward.

Why do multicamera records produce different total row counts?

The structured list and tabular output expand one take into camera-specific rows. The readable report remains one row per take, so its total row count can be lower for the same source records.

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. Figures current as of 24 September 2026.