A seed is not a provenance record: documenting generative art outputs

A seed is useful when you want to revisit a generated image. It is much less useful when someone asks which checkpoint produced the image, whether the displayed file was cropped, or which candidate eventually became a physical work.

Those questions need a small chain of records: run → output → selected image → production file → physical proof. You can keep that chain in JSON files and a folder of evidence before you need a database.

This article proposes a lightweight record format for people building generative art workflows. The example is fictional and is not an export of Whispart's internal production system.

Give the run and the image different identities

Treat a run as the configuration used to generate a set of candidates. Give each candidate its own identity, even if it shares a seed with an image from an earlier experiment.

For the run, preserve:

• The exact checkpoint file, with a checksum to identify its bytes.
• The generation code revision and resolved configuration, including default values.
• The software environment and relevant hardware information.
• A dataset version reference, when you control the training process, with its source-review records stored separately.

For each output, record the run ID, sampling inputs and the actual exported file. Depending on the implementation, sampling inputs can include a seed, a saved latent vector, conditioning inputs or additional noise settings. Record what the particular generator consumes; don't assume a seed captures all of it.

Even a carefully recorded configuration is not a promise of identical pixels everywhere. PyTorch's reproducibility documentation explains that results can differ across releases, platforms and CPU/GPU execution. Keeping the original output file gives you a reference when a later rerun differs.

Record what happened after generation

Suppose a fictional studio selects candidate-0042, crops it for presentation and later exports a separate file for printing. If all three images are called final.png, the history becomes difficult to reconstruct.

Instead, preserve the original candidate and record each derived file with its parent and the operation performed. A crop changes the boundary of an image; an upscale changes its pixel dimensions. Neither operation should silently replace the original record.

Selection is a separate event. Record which candidate was selected, by whom, when, and why. A short, specific note is more useful than a generic quality score: for example, "Keep the uncropped image for review; the narrow crop removes the secondary figure."

This separation matters when generated images become physical objects. Whispart's illustrated GAN process distinguishes a model, an output, a selected image and an authorized physical release. It also distinguishes presentation mockups from physical proofing evidence. The record format below applies that distinction to file management; it does not imply that the studio uses this particular schema.

A small example you can adapt

The following is an illustrative record with unresolved fields, not a completed production record. Paths and IDs are invented. Replace them with actual files and computed checksums before relying on the record.

{
  "schema_version": 1,
  "example_only": true,
  "run": {
    "id": "demo-run-01",
    "checkpoint_file": "models/demo-checkpoint.pkl",
    "checkpoint_sha256": null,
    "code_revision": null,
    "configuration_file": "runs/demo-run-01/config.json",
    "environment_file": "runs/demo-run-01/environment.txt",
    "dataset_version": null
  },
  "output": {
    "id": "candidate-0042",
    "run_id": "demo-run-01",
    "seed": 42,
    "sampling_inputs_file": "runs/demo-run-01/inputs-0042.json",
    "file": "outputs/candidate-0042.png",
    "sha256": null
  },
  "presentation": {
    "id": "presentation-0042-a",
    "parent_output_id": "candidate-0042",
    "operation": "crop",
    "file": "presentations/candidate-0042-crop.png",
    "sha256": null
  },
  "selection": {
    "status": "pending",
    "selected_asset_id": null,
    "reviewer": null,
    "reviewed_at": null,
    "reason": null
  },
  "production": {
    "source_asset_id": null,
    "print_file": null,
    "print_file_sha256": null,
    "proof_photo": null,
    "proof_result": "not_reviewed",
    "release_id": null
  }
}

Notice that the presentation crop exists while selection is still pending. Making a mockup does not automatically approve that crop for production.

Here is a concrete way to use the example:

1. Compare the original output with the presentation crop. If the original is selected, set selected_asset_id to candidate-0042; if the crop is selected, use presentation-0042-a. Save the reviewer, time and actual reason.
2. Export the print file from the selected asset. Record that asset's ID as production.source_asset_id, and compute the checksum of the exported print file.
3. When a physical proof is made, attach a photograph of that specific proof and record the review result. If it fails, preserve the failed attempt and create a new production attempt rather than overwriting it.
4. Assign a release ID only when the studio's release decision is complete. Keep any edition policy in a separate, explicit record.

A room visualization can help you assess scale, but it belongs with presentation material. It cannot fill the missing proof_photo field.

Check the relationships before you trust the record

Start with a few checks that catch ordinary mistakes:

• Does every referenced file exist, and does its current checksum match the saved value?
• Does each derived asset point to the actual parent used to create it?
• Does the production file trace back to the selected asset?
• Does the proof evidence identify the same production attempt?
• Are unresolved fields still visibly unresolved?

A checksum helps detect a changed file. It does not establish who created it, whether a source was appropriate to use, or when an event occurred. Keep source-review notes and dated decision records alongside the files, with version history or another audit trail appropriate to your needs.

If you retain only one thing from an exploratory session, keep the actual output and its run reference together. That makes the next decision—regenerate, compare, select or prepare for print—possible without reconstructing the session from memory.

---

Published by Whispart Studio. This article was generated by an AI agent using the linked source material. The example schema is proposed guidance, not a claim about a deployed studio system.