Find an output, its original, and its settings without hesitation.

Choose a structure you can explain

Create a folder named after the project, then a few locations with clear roles. A person's name or today's date is not always enough to understand the contents six weeks later. A note placed at the root should explain where the inputs, the work-in-progress runs, and the chosen delivery are.

The University of Cambridge recommends agreeing early on a filing system and consistent naming rules. The template below is a BriefGPU suggestion for a small session. Adapt it if your software already imposes a project structure; do not move its linked resources without checking that the project can find them again.

Keep the received input recognizable

Before the first processing, list the sources with their original name and location. Keep an untouched version of these inputs, as Cornell recommends for raw data. Simply naming a folder "originals" does not protect the content: point the software to a different output folder and check its behavior on a test file.

If you need to convert or crop an input before processing, treat this preparation as an identified step. Keep the link to the received source. You will then be able to tell apart a defect that was already present, a preparation issue, and an effect of the GPU processing.

When a new source replaces the old one, note the version and the outputs to review. Do not silently overwrite a file used by a run you want to understand. The rule is to keep the useful provenance, not to keep every working copy indefinitely.

Give every unit of work a stable identifier

A short identifier like image-001 helps track the same input across several runs. Its role does not change when an output is accepted. Keep the validation status in the inventory rather than constantly renaming files to "good", "bad", or "almost-final".

For one hundred inputs, the numbers 001 to 100 provide a regular reference point. Add a business reference when it is needed for the delivery. Do not assume that two files called photo.png, received in two different subfolders, are the same thing. The full path of the input must stay associated with the identifier.

Choose names compatible with the destination tools. Windows reserves in particular the colon, question mark, and asterisk characters; its ordinary rules also do not reliably distinguish two names by their capitalization alone. A name like image-007_run-02.png avoids these ambiguities. Check the specific constraints of your other tools rather than promising universal compatibility.

Example: two runs, a single collection of sources

Suppose eight images arrive in two folders. The inventory assigns image-001 through image-008 and keeps their original paths. The first pass uses the trial-01 settings; all its outputs go into the corresponding folder. A defect on image-003 and image-006 leads to a second trial limited to those two inputs.

The six satisfactory results from the first trial are not recalculated just to make the folder more uniform. The inventory shows which output was kept for each input. Delivery v01 contains eight files bearing the expected names, even though their origin is split across two trials. This example describes an organization; it does not assume that the settings necessarily improve the results.

Keep the settings at the time of the trial

A file named trial-02.txt can be a simple note if the software cannot export its parameters. Write down the tool version, the model if any, the inputs concerned and the values you chose. Add the reason for the change compared with the previous trial. A screenshot can supplement the note when the parameters are only visible in a window.

Avoid a single "current settings" note that gets replaced after every pass. It would explain the latest attempt, but no longer the older outputs. If several trials use the same parameters, reference the same identified configuration instead of copying it needlessly.

The software version and the parameters make a result easier to explain; they do not by themselves guarantee an identical reproduction. Some applications require other information or resources. Follow their documentation for a precise rework need, especially when it involves a training state.

Keep a log that explains the decisions

The log complements the inventory. The inventory answers "where does this input stand?"; the log answers "why did we change?". A few dated lines are enough: trial concerned, observation, decision and next check. Avoid copying every message from the software if no one will be able to use it.

For the example, a useful line would be: "trial-01: incomplete outlines on image-003 and image-006; redo these two inputs with setting B; keep the other outputs pending final validation." After review, add the actual decision. Do not rewrite the initial observation as if the defect had never existed.

Reread technical logs before passing them on: they can contain private paths or means of access. Keep secrets separate from the documentation folder. A note intended for a colleague should explain the work with the information that person needs.

Distinguish storage, delivery and backup

The working folder keeps the trials useful to your reasoning. The delivery folder gathers what the recipient must receive. The backup keeps the necessary items in another location, with a copy check. Three folders placed side by side in the same space do not by themselves fulfill these three functions.

Do not copy every source into each trial folder. Link outputs to inputs through the inventory. For delivery, a selected copy can be useful so you hand over a self-contained set; in that case note its origin and version. For backup, follow the dedicated guide, which details the inventory and the verification after transfer.

Before cleaning up the discarded variants, check which ones are still needed to explain a decision or redo the work. This organization does not impose any retention period. It lets you decide what is worth keeping, then find the copy that is the reference.

Do a check using a randomly chosen output

Choose a delivery file without opening your software first. From its name and the inventory, trace back to its input, the trial that produced it, its settings and the acceptance decision. Repeat with an output that required rework. If the process depends on your memory, a link is missing in the tracking.

Next, check the quantities: number of expected inputs, retained results, blocked items and excluded variants. A tidy folder can still be incomplete. This quick check is done when the discrepancies have a reason and someone else can understand which files to use.