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 the same rewrites whenever a file is exported and read back.
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 (including sound timecode Sound TC), 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 slugline and summary behaviors to distinguish on a 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.
The period is handled conditionally. An import keeps a prefix such as INT. exactly as it was read, and an export adds a period only when the value has none, so one round trip does not produce a double period; what can repeat is the title and day/night information inside the heading. 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 export 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. Missing Values in a Handoff: What Each Blank Means can help distinguish absent attributes, empty values and placeholders, but this page remains limited to the FDX round trip itself.
Hard boundary: the behavior can be described, but four questions still need file-level evidence
Slugline layering, summary replacement, omission of the length attribute when eighths are 0 followed by a 1/8-page default on read-back, resetting the re-imported scene state to “not shot,” and the failure to restore note/summary paragraphs to their former script-item positions (with script-item order assigned again) are observable when the app exports a file and reads it back. Only four questions remain outside what this page can settle:
Which additional fields a particular real FDX loses. Import reads only the five attributes listed above; identifying what else a specific file loses requires comparing that actual file field by field.
Which scenes the duplicate filter actually removes. The filter is in place, but the exact set of affected scenes depends on the input file and must be checked against the import result.
Actual interoperation with third-party screenwriting software. This page does not promise a lossless round trip; the result of opening, saving, and re-importing in third-party software depends on the file you actually use.
How much these recurring rewrites affect a given file. All these rewrites do occur; how much a particular file’s slugline, summary, or length changes requires comparing the actual exported file with the returned result.
The public boundary is therefore: a round trip does not guarantee character-for-character preservation. Do not expand a settled behavior into a claim that every file changes by the same amount, and do not describe a third-party application’s actual result as accepted. The receiver should inspect the actual exchange file and compare the returned slugline, length, summary, and state.
A round trip does not guarantee character-for-character preservation; all these rewrites do occur, while the actual change in any given file still needs checking.
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. This page does not vouch for how third-party script software opens, saves, and re-imports a file; verify the one you hold. The public boundary stays at a round trip not guaranteeing character-for-character fidelity.
Axiom One LLC — SlateX