What FDX Exchanges—and What It Does Not Carry
In SlateX, FDX is used for script-structure exchange. Episodes, scenes, scene headings, day/night information, page length, script items, and revision color can participate in this path. Shooting results do not. The current import does not create shots, takes, shoot days, or camera setups. So an FDX import can establish script structure without establishing a production record, and a successful round trip should not be described as character-for-character preservation.
FDX is a carrier for script structure here, not a container for shooting results.
What the import actually creates
The current SlateX import creates three classes of working objects: episodes, scenes, and script items. It does not create shots. It does not create takes. It does not create shoot days or camera setups. Production presets such as unit, director, and cinematography leadership are not created by this import flow either and remain a separate manual concern.
That boundary defines the useful scope of FDX. It can turn a script file into scene and text structure that later production records can refer to. It should not be described as making a project ready for shooting simply because the script structure exists. What import creates, and what it does not, is covered in What Script Import Creates—and What It Does Not.
Content before the first readable scene heading has nowhere to attach
A scene is created only once a readable scene heading is encountered. Paragraphs before the first such heading do not have an existing scene to attach to, so they do not become imported scene content. Opening material that appears before the first scene heading falls outside that path.
An empty scene-heading text also does not produce a scene object. The precise statement is structural: the scene-creation step requires usable heading text. There is no need to assign a product motive to the missing content; the relevant fact is that the current path has no scene object to carry it.
“Parsed successfully” can still mean no scenes were created
There is another boundary that looks less like a failure. When a well-formed FDX yields no scene at all, SlateX reports that the file contains no readable scenes and does not open the scene picker. The case that is easy to miss is a partial read: the picker opens as usual while the list holds fewer scenes than the file contains.
That makes “the file parsed” and “content was imported” two different checks. The first tells you the file could be read. The second requires looking at the scenes that were actually created and whether script items exist under them.
A success state does not prove that any scene entered the project; inspect the structure that was actually created.
A round trip has deterministic rewrites
A round trip shows several deterministic changes. When a scene that originally came from FDX is written again, the written heading can append title and day/night information to a heading that already contains those elements. The period is added conditionally: a heading that already has one is left alone, and a heading without one gets a single period, so a round trip does not produce a double form such as INT...
The summary is also asymmetric. Summary information can be read, but writing the project back out does not carry the same summary, and a later import can replace the scene summary with the first body paragraph. If the page length is zero, no length attribute is written; when that file is read again, the missing length falls back to 1/8 page. Shooting status is not preserved through this structural exchange either; a re-import returns to the unshot state.
These observations come from SlateX’s own import and export results. They do not prove how another screenwriting application will behave. The allowed external statement is narrower: a round trip is not guaranteed to preserve the text exactly.
Shooting information is outside this exchange path
Shots, takes, shoot days, camera setups, timecode, ratings, media paths, and other shooting results are not carried by the current FDX path. The import does not create those objects, and the export does not fold them into the script structure.
When something does not return, the useful question is therefore whether the exchange contains an object or field that can carry it. The absence should not be described as an intentional decision to discard the information when the verified fact is simply that no field carries it.
A non-lossless round trip can still have a clear purpose
FDX remains useful for moving script structure. It can bring scenes and script items into SlateX and can write the current script structure back out. The boundary is that this should be treated as structural exchange rather than as a continuously editable working-document loop in which every character and state survives unchanged.
A receiver should inspect the structure that is present in the file and not treat “it opens” or “it can be imported again” as proof of text fidelity.
FAQ
Does an FDX import automatically create shots and takes?
No. The current import creates episodes, scenes, and script items, but it does not create shots, takes, shoot days, or camera setups.
Does a successful parse mean scenes were imported?
Not necessarily. When nothing can be read, SlateX reports it and the picker never opens; when only part of the script parses, the picker opens as usual, so the number of scenes actually created still needs to be checked.
Can an FDX round trip be guaranteed to preserve a scene heading exactly?
No such guarantee is supported. A round trip can append title and day/night information to a heading that already contains those elements, and a later import can replace the scene summary with the first body paragraph, so the only outward statement for this family is that a round trip is not guaranteed to preserve the text exactly; what counts is the difference you measure in the file you hold before and after the round trip.
Why do some shooting records not come back through FDX?
Because the current FDX exchange carries no corresponding shooting object or field. That is a carrying boundary, not a claim about product intent.
Axiom One LLC — SlateX