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 also have no write path in this import flow 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.

Content before the first readable scene heading has nowhere to attach

The current parser begins building a scene when it encounters a readable scene heading. 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. A well-formed FDX with no readable scene heading can still reach the parser's success branch. SlateX can then present the scene picker with an empty list and no additional warning.

That makes “the file parsed” and “content was imported” two different checks. The first tells you the parser completed. 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

The current read and write paths produce several deterministic changes. When a scene that originally came from FDX is written again, the heading builder can append title and day/night information to a heading that already contains those elements. The importer preserves a period in the heading prefix, while the exporter appends another period, so a round trip can produce a double form such as INT...

The summary path is also asymmetric. Summary information can be read, but the current export path does not write it back into the same field, and a later import can replace the scene summary with the first body paragraph. If the stored page length is zero, the exporter omits the length attribute; 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 read and write paths. They do not prove how another screenwriting application will behave. We have not completed a real third-party open-save-reimport acceptance pass, so 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 there is no carrying field or write path.

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.

Two narrower questions belong in their own pages

This parent page answers what FDX carries and what falls outside the current exchange. Two narrower questions should remain separate: exactly what cannot come back on a round trip, with each loss traced to a missing field, object, or write path; and exactly what an import creates, separating episodes, scenes, and script items from the shooting objects it does not create.

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. A well-formed file with no readable scene headings can still reach the success path and show an empty scene picker, so the created scene structure still needs to be checked.

Can an FDX round trip be guaranteed to preserve a scene heading exactly?

No such guarantee is supported. The current read and write paths can duplicate heading components and punctuation, so the accurate statement is that a round trip is not guaranteed to preserve the text exactly.

Why do some shooting records not come back through FDX?

Because the current exchange path has no corresponding shooting object or field for them. The verified explanation is the missing carrying path, not a claim about product intent.

Axiom One LLC — SlateX. Figures current as of 24 September 2026.