Keep an asset record your future self can understand

Record the source while it is easy

Save the original export, the tool and model information available to you, the generation date, the prompt and any reference inputs. If a seed or workflow is relevant, keep that too.

Record where reference material came from and the permission or license you relied on. For generated assets, keep a dated note or copy of the terms applicable to the account and use you planned.

This record supports review; it doesn't guarantee that every intended use is permitted. I'd flag uncertainty while the source is still available to investigate.

Separate the source from the game export

Keep the editable or high-resolution source apart from the resized, compressed file used by the game. Record important edits such as background removal, recoloring, looping or combining several inputs.

Use stable descriptive names and a short manifest that maps the shipped file to its source. A teammate should be able to replace the inventory key without guessing which of twelve numbered images it came from.

If you revise an asset, retain enough version history to recover the previous shipped result. A visual improvement can still introduce an edge, timing or licensing problem.

Review the files that actually ship

Before publishing, inspect the release's asset list rather than assuming that your source folder describes the build. Remove experiments and unused files that don't belong in the distribution.

Check uncertain records, missing credits and assets whose intended use changed. A private prototype and a commercial release may raise different questions under the relevant terms.

I'd make this a short recurring habit instead of a huge cleanup before launch. Five minutes spent recording a source today can save an hour later, and it makes creative changes much easier when you know exactly which file and decision to revisit.

Sources & further reading

• ComfyUI: workflow JSON — accessed Sep 9, 2026