What an Exported FDX Does Not Bring Back
An FDX written by SlateX and then imported back into the app is not a reconstruction of the original project. At file level it writes the project title, while scene exchange is centered on scene number, Int./Ext., scene name, time of day, eighths, revision color, omitted state, page number, and script items; app data outside that written scope cannot return through this file. More importantly, even values inside the written scope can undergo deterministic rewrites when the export and import rules are applied in sequence.
What can return through FDX is limited first by what is written out; even an in-scope value is not guaranteed to return character-for-character.
The written scope sets the ceiling for what can return
Across file-level and scene-level output, the export carries the project title together with scene number, Int./Ext., scene name, time of day, eighths, revision color, omitted state, page number, and script items. Shots, takes, camera records, timecode, media paths, and similar on-set records are outside this FDX structure, so this file cannot restore them.
That is the division of work between What FDX Exchanges—and What It Does Not Carry and this page. The parent page explains the exchange scope; this page stays narrower and examines what happens when the same script exchange file goes out and comes back, including information that has no return path at all.
Three values are deterministically rewritten by the round trip
One rewrite is slugline duplication. For a scene imported from FDX, the scene name keeps the whole original heading while Int./Ext. and time of day are also stored separately; export then rebuilds the heading as “Int./Ext. prefix + whole original heading + delimiter + original time of day,” so the heading and time-of-day text are layered in again. A scene created manually inside the app behaves differently at this point because those three parts begin as separate stored values, so the same duplication has no source there.
Another rewrite is period duplication. The reader can retain the period in a prefix such as INT., while the writer adds another period after Int./Ext., so one round trip can produce a double period. This is the combined result of the read and write rules, not a claim about what third-party script software does.
The third rewrite is summary replacement. On import, note or summary material can feed the scene summary, and when no such pending summary exists, the opening Action or General paragraph can also be used as the summary, so the summary may contain the full action text rather than a plot synopsis. The export side does not write the scene summary back through a matching attribute, so a later import can replace that position again with the opening Action or General paragraph.
Three other return-path changes should be kept separate
When a scene has 0 eighths, the writer omits the length attribute; when the file is read again, a missing length becomes 1/8 page, so “0 or absent” can return as 1/8 page. Re-import also writes the scene state as “not shot,” so the FDX cannot restore the previous shooting state. Note or summary paragraphs do not return as script items in their former positions, and script-item order is assigned again.
These changes do not mean the file is corrupt. They show that “what the format writes” and “how import creates records” are different questions. Four Shapes of a Missing Value can help distinguish absent attributes, empty values, and placeholders, but this page remains limited to the FDX round trip itself.
Hard boundary: code inference is not third-party round-trip acceptance
Slugline duplication, the double period, and summary replacement follow directly from combining the current writer and reader rules. We have not yet completed a real “open, save as, and re-import” pass through third-party script software, so the public boundary is: a round trip does not guarantee character-for-character preservation.
That boundary also limits further claims. The deterministic app-side behavior should not be rewritten as “every third-party script tool will do this,” and an untested real-world pass should not be described as accepted; a receiver should verify the actual exchange file and the returned slugline, length, summary, and state.
A round trip does not guarantee character-for-character preservation; the rewrite paths are established in code, while a real third-party open-save-reimport pass still needs file-by-file verification.
FAQ
Can FDX bring shots and take records back with the script?
Those on-set objects are not available from the current written structure. They are outside this FDX exchange scope and are not recreated merely by re-importing the file.
Why can the slugline gain another prefix and time-of-day segment?
An imported scene retains the whole original heading while Int./Ext. and time of day are also stored separately, and export concatenates those parts again. A manually created scene behaves differently here because the three parts begin as separate values.
Why can the summary become action text?
When no note or summary is pending, the opening Action or General paragraph can be used as the summary, while the summary has no matching write-back path. A later import can therefore replace that position with the full action paragraph.
Do these findings mean a third-party script application has passed a round-trip test?
No. We have not completed that real third-party round trip, so the receiver should verify the actual file; the public boundary remains that a round trip does not guarantee character-for-character preservation.
Axiom One LLC — SlateX. Figures current as of 24 September 2026.