What an ALE File Is Actually For
In SlateX, an ALE is a tab-delimited text list made of a header section, a column section, and a data section. Its job is to hand the receiver checkable information about what a row refers to, where that material sits in time, and which scene and take it belongs to. It does not decide which take is good, and it does not carry shot parameters, media paths, or channel mapping. Whether it can be used in a particular receiving workflow still depends on the receiver checking the columns.
An ALE supplies identity and time information that can be checked; it does not certify that those values have already been verified.
What the file looks like
The current SlateX ALE starts with header information, then a fixed set of column names, and then data rows. Columns are separated by tabs, so the file behaves like a text table with explicit fields rather than a container for the media itself.
Rows are generated per camera. A take with several cameras can therefore occupy several rows. A take with no camera data still produces a fallback row. This means an ALE row is closer to a camera-level delivery record than to a rule that “one row equals one take.”
Ask where each value came from
It is useful to read ALE values in three source categories.
The first category comes from on-set records or user-entered information: scene and take identity, notes, director text, camera notes, and related recorded context. Their correctness depends on whether the source record matches what happened on set.
The second category is generated or derived by software. End, for example, can be calculated from the in point and duration when no independent out point is present. Names, formatted reel values, and some frame-rate representation also pass through generation logic. A derived value is not an independent second observation; it still depends on its inputs.
The third category is fallback output created when source information is missing. Missing timecode can appear as 00:00:00:00, and missing camera identity can result in reel- or sound-roll-looking defaults. Those strings can look ordinary even though their source is a fallback path, so the receiver needs to check them against the on-set record or the media.
Ask “where did this value come from?” before asking only “does this value look syntactically valid?”
What an ALE can hand to the receiver
The current columns can expose material name, start, end, duration, scene, take, reel, sound roll, frame rate, comments, camera identity, and related fields. That makes the file useful for passing identity and time-position clues into a receiving check.
There is an important identity boundary: Tape and Reel are currently populated from the same source value. They should not be treated as two independent identity signals simply because they appear in two columns.
The end position also may not be an independent observation. When timecodeOut is absent, the current generator calculates End from the start position and duration. A receiver should therefore verify the source of Start and Duration, then treat End as a derived result rather than a separate measurement.
What the ALE does not contain
The current ALE has no rating or circled-take column. It also has no shot-number column, lens, ISO, aperture, resolution, media path, channel map, or sound timecode. Those facts may exist elsewhere in a production record, but their existence elsewhere does not mean the ALE carries them.
That boundary also means the ALE does not decide which take was preferred on set. If the receiving side needs the recorded take judgment, it has to come from another artifact or the source record rather than being inferred from this file.
Why ALE row count differs from the readable report
The same set of take records is expanded differently across outputs. Camera-oriented tabular outputs create rows per camera, while the readable report remains one row per take. A multicamera take can therefore increase the ALE row count without increasing the report row count in the same way.
This is not a difference that should be resolved by matching row numbers. Cross-file verification should return to scene, take, and camera identity rather than assuming that row N in one artifact represents row N in another.
What to do after receiving an ALE
This page stops at the purpose and boundaries of the format. The already published “What to Check Before Using an ALE for Matching” continues with the receiving procedure: identify what each row belongs to, then verify reel, material name, time position, frame rate, and the source of missing-looking values. For behavior in a specific receiving system, the receiver should check each column against its own import template.
FAQ
Does an ALE include the media files themselves?
No. SlateX's current ALE is a text list. It does not include media paths and does not package the media itself.
Is End always an independently measured time position?
No. When an independent out point is missing, the current generation path can calculate End from the start position and duration, so it needs to be checked as a derived value.
Can Reel and Tape be treated as two independent identity checks?
No. The current output populates them from the same source value, so two columns do not represent two independent confirmations.
Why can one take appear on several ALE rows?
Because the current ALE generates data rows per camera. A multicamera take therefore expands into several rows, so total row count is not the same thing as total take count.
Axiom One LLC — SlateX. Figures current as of 24 September 2026.