Missing Values in a Handoff: What Each Blank Means
A missing value in a handoff file does not always look like an empty cell. During receiving, separate at least four shapes: an empty string, an explicit dash placeholder, a plausible-looking generated default, and an all-zero timecode value. Each can mean that no confirmed value is available, but they are produced differently and should not be collapsed into one category.
Missing data does not always look empty. Some missing values look almost indistinguishable from ordinary records.
An empty string is the visible gap
In the tabular handoff, many missing fields are written as empty strings. When there is no camera record, camera-related fields can be empty. Missing timecode-in, shooting-day, or other optional data can also appear as blank cells.
A blank is easy to notice, but it still does not tell you why the value is absent. The source record may never have contained it, or the software may not have had a usable source for that field. Receiving still requires a source check.
Different delivery formats do not use the same missing-value strategy. A receiver should not take the prevalence of empty strings in one file and assume another file represents absence the same way.
A dash is an explicit placeholder, not a business value
Some fields write - when they hold nothing. Our own Daily Log PDF is that shape: director, unit, crew call and wrap come out as a dash when they were never entered. The dash is not a real name, number or status — it tells the receiver there is no value here. The reverse also holds: the two machine-readable files never show it. In ALE and CSV a missing value is an empty string, so a rule of “a dash means missing” walks straight past every blank cell in them.
The important boundary is that - is not the universal missing-data marker for the whole file. Other fields can be empty, receive a generated identifier, or receive zero timecode. A receiver cannot build one rule that says “missing means dash.”
Interpret the dash by field. In one column it can be an explicit placeholder, while another column may never use it.
Generated identifiers can look like genuine records
Without camera context the two human-readable files can show reel and sound-roll as A001 or S001: a camera letter plus a three-digit increment the software counted. On screen that is indistinguishable from a real card name, so a well-formed string alone never tells you whether anyone confirmed it on set.
In the machine-readable files the same fact travels a different road. The four ALE cells used to recognise a source — Tape, Reel #, Soundroll, Camroll — take only the card number you typed, and stay empty when you did not; a counted number is never pushed in. CSV hands over both columns side by side: the display number the software assigned, and the real card number you transcribed. The split exists so someone compares them.
These values cannot prove their own provenance from inside the handoff file. Compare reel, clip, and media naming with the on-set record or the media itself.
“Looks valid” describes the string shape. It does not establish that the source was verified.
Zero timecode can be real zero or missing data
00:00:00:00 needs the same caution. It is a syntactically readable timecode string, so a format check will not flag it as empty, and another tool’s generator can write it when usable timecode or duration is missing — which is exactly what makes it dangerous. Our own three handoff files no longer write it: a timecode that was not recorded, or fails a shape or range check, goes out empty. Absent stays absent instead of being padded into something legal-looking.
The handoff alone therefore cannot distinguish a genuine zero point from a missing value replaced by zero. The receiver has to consult the on-set record, media metadata, or another traceable source. A syntax validator cannot make that provenance decision from the timecode shape alone, so source verification remains necessary.
The same caution applies to the calculated span: Duration comes from the two readings, and if either one is missing the cell ships empty. A complete-looking calculated field does not prove that every input behind it was observed.
Do not copy one missing-value rule across formats
SlateX’s own rule is short enough to state in one pass. In the two machine-readable files a missing value has one appearance: an empty string — no dash, no all-zero timecode, and a frame rate the camera never declared leaves that cell empty in both, so there is no file giving 25 while the other gives 24. The dash belongs to the human-readable Daily Log PDF alone. Counted numbers of the A001 family appear in the human-readable columns of CSV and PDF, and inside the ALE they travel as part of the file name in Name; the cells used to recognise a source never take one. One more blank worth knowing: in the ALE a cell can be empty although the record holds the value, because that column cannot carry that alphabet — the text ships verbatim in the CSV and the PDF.
So the correct receiving rule is not “missing values are represented by one symbol.” Build the check around the actual format and column: which fields can be blank, which use placeholders, which can receive valid-looking defaults, and which time fields can become zero.
The current handoff does not add a separate provenance flag saying “this value was generated.” When a fallback and a genuine value look the same, responsibility for confirming the source remains with the receiver. Use the source record rather than guessing from appearance.
For the receiving sequence that follows these checks, see “How to Decide Whether a Handoff Can Move Forward”.
FAQ
Are an empty cell and - the same kind of missing value?
They can both indicate absence, but they are different output forms and are not used by every field in the same way. Interpret them by column.
Does A001 in a handoff prove that A001 was the on-set reel?
No. That column is a display number the software assigned — a camera letter plus a counted sequence, formatted like a reel. The card number transcribed on set sits in another column, and the ALE’s identity cells stay empty rather than taking the assigned one. Compare the two.
Can 00:00:00:00 be accepted as a genuine zero point?
Not from the string alone — in any file. It can be a real zero, and it can also be what another tool’s generator writes when nothing usable was there. Trace it back to the source. Our own three handoff files no longer write it: an absent value goes out empty.
Why not use one missing-value rule for every delivery format?
Because the same data is written differently depending on the carrier: the human-readable report uses a placeholder, the two machine-readable files leave everything empty, and counted numbers appear in the human-readable columns and inside the ALE file name. Build the check per carrier and per column.
Axiom One LLC — SlateX