Where Handoff Files Live After Export—and How Long They Last

When one generation finishes on the export page, the result is not a long-term archive location but the current set of files for the selected scope. Filenames and the subfolder are arranged by scope and date, but the final step into the user’s hands still goes through the system share sheet or a save-location choice on the computer.

The files listed on the export page mean the current deliverables are ready; it does not mean they have already been stored in a long-term location.

What names one export produces

A handoff name joins the project title, the scope, the artifact type and the identifier with underscores. A single-day scope puts the day number and date after the project title, as in Title_Day03_20261008; whole-project scope replaces that day segment with All, as in Title_All. The files add the artifact type and eight identifier characters to that stem: the Daily Log PDF is written as …_Report_XXXXXXXX.pdf, an ALE as …_ALE_XXXXXXXX.ale, and the CSV detail file as …_Log_XXXXXXXX.csv; when reconciliation is selected there is also a …_Reconcile_XXXXXXXX.csv for two departments to check against each other, not for import. A name you see on screen and the artifact-type word inside a file name are not the same vocabulary: the page labelled Daily Log exports a PDF whose type token is Report, and the Log token belongs to the CSV. Match files to screens by format and by the shared stem, not by the token word alone. Those eight X characters are the first eight characters of one export identifier, shared by the batch, so files from one generation can be compared by their shared stem and that identifier fragment.

The export folder uses the same stem as the files and does not branch by interface language or date presentation: the same project and day produce the same folder and filenames in any interface language. The date segment is always written in the compact form 20261008; if no date was recorded for that day, the segment is omitted rather than filled with today’s date. These shapes are useful for checking the current scope.

Why changing one option removes the previous result from the export page

Switching formats, choosing another day, or changing export scope triggers another generation. Once the next generation begins, the export page shows only the current result and replaces the previous completed list; after changing an option, confirm the names, dates, and scope in the current file list rather than treating the previous list as retained version history.

Leaving the export page is a different event. Exiting that page does not alter a directory that has already been delivered through the system share or save action, so “regeneration replaces the current result on the page” and “a copy already placed elsewhere remains at that destination” should be read separately. The receiver should identify which generation was actually received rather than relying only on file extensions.

From the export page to a real saved location

On a phone, the directory is handed to the system share sheet, where a person still needs to choose a real destination such as a file location or another application. On a computer, the user chooses a save location and the current deliverables are copied there. In other words, export prepares the files, while the save or share action places them at a location chosen by the user.

The export page itself is not a library that can later be reopened at will; how long the files last depends on where you save them. A practical handoff check is to confirm that the current directory has been copied to a fixed location and then reopen that destination to check the filenames. Why a Handoff Cannot Hand Back a Path to the Media covers why a path inside them does not resolve on the receiver’s machine, while persistence of the exported files still depends on the chosen destination.

The receiver should verify the identifier prefix, date, and export scope, and confirm that the current deliverables have been saved to a fixed location rather than only appearing on the export page.

Scope also changes which deliverables exist

A generation prepares the artifact types you selected, and whole-project scope does not include the PDF. That boundary should be checked directly from the selected scope rather than compressed into a vague claim that formats merely depend on options; when the scope is the whole project, the receiver should confirm the ALE and CSV in the actual file list instead of waiting for a PDF in the same folder.

This page also does not promise a compressed archive. What is shared or saved is the prepared directory and its files, while any later presentation depends on the destination and receiving workflow. When ALE content needs review, What to Check Before Using an ALE for Matching can be used for column-level verification, while whether the files have truly been stored still depends on the copy at the user-selected location.

FAQ

Are exported files automatically placed on the desktop or in Documents?

No; the current generation first appears on the export page, then the computer requires a save location while the phone requires a destination in the system share sheet.

How can files from one generation be recognized?

Compare the shared stem and eight-character identifier across the files: a single-day name looks like Title_Day03_20261008, while whole-project scope looks like Title_All.

Why does the previous file list disappear after one export option changes?

An option change triggers regeneration and replaces the previous list with the current result; after the change, confirm the names, dates, and scope shown in the current list.

Does a whole-project export also contain a PDF?

Whole-project scope does not include PDF; the receiver should verify the actual ALE and CSV list and save the directory that needs to be retained to a fixed location.

Axiom One LLC — SlateX