[Pixel Post] SpriteDX – Runs, Recovery, and Reproducibility

In SpriteDX, every time you click Generate, we create a new run_xxxx folder. That folder is more than just output files—it’s a self-contained recipe of everything needed to reproduce that generation: parameters, pipeline JSON, environment, seeds, and stage manifests.

Why Runs Matter

• Reproducibility – given a run folder, you can recreate results bit-for-bit.

• Audit trail – every completed run is immutable, so you can always go back and see exactly what settings produced what outputs.

• Incremental speedups – when you change a single parameter, only the affected stage and its downstream stages rebuild; everything else is reused.

Run Manifests

Each run has:

• run.json – captures the global pipeline, UI state, seeds, and asset catalog.

• stages/<name>/manifest.json – records inputs, hashes, and outputs for that stage.

This structure makes it easy to tell which stages can be skipped or reused.

Recovery Workflow

Navigation into a run_xxxx folder does not automatically change your editor. You stay in control. If you want to restore settings from a past run, the header shows a clear Recover & Continue button. From there you can:

• Recover only – repopulate the editor with that run’s parameters.

• Recover & Continue – repopulate and immediately start a new run, reusing what hasn’t changed.

• Resume – if the run was incomplete and matches your current params, continue in place.

This keeps runs immutable by default, while making it fast to pick up exactly where you left off.

The UX Philosophy

• Explicit, not automatic – params don’t change just because you clicked into a folder.

• Immutable history – completed runs are never mutated.

• Fast reuse – fingerprints (hashes of params, graphs, assets, seeds) ensure only what’s necessary recomputes.

---

That’s it: runs as recipes. SpriteDX treats every generation as a build artifact you can always come back to, recover, and continue—just like a compiler build, but for generative art.