Making generative projects reviewable: versions, prompts and evidence

01 / Why a model name alone is not enough

A model repository can update configs, weights or dependencies; the same prompt can yield different outputs when preprocessing, scheduler, seed, precision, sampling parameters or software stack changes. A reviewable inference should answer: Which version ran? What were the inputs and parameters? How was the output checked? How can someone reproduce it within the applicable license?

Keep method notes, run records, outputs and limitations distinct. A tutorial example is not user-study or performance evidence; synthetic images and videos do not replace datasets, baselines, ablations or statistical analysis.

02 / A minimal generation manifest

Record repository ID, revision or commit, checkpoint provenance and a shareable checksum. Capture the prompt, a source summary and preprocessing. Log code version, Python/PyTorch/CUDA, hardware, scheduler, steps, guidance, resolution and seed. Track output path, human-review checks, failure cases and limitations. For private media, retain only a minimal internal identifier or hash; do not publish faces, voices or credentials.

{
  "task": "text-to-image",
  "model": {
    "repo": "stabilityai/stable-diffusion-xl-base-1.0",
    "revision": "<immutable-commit-or-release>",
    "checkpoint_sha256": "<verified-hash>"
  },
  "input": {
    "prompt": "<exact prompt>",
    "negative_prompt": "<exact negative prompt>",
    "source_media_ref": "<licensed source or internal ID>"
  },
  "inference": {
    "seed": 20261020,
    "scheduler": "<scheduler name and config>",
    "steps": 30,
    "guidance_scale": 6.0,
    "width": 1024,
    "height": 1024
  },
  "runtime": {
    "code_commit": "<commit>",
    "python": "<version>",
    "pytorch": "<version>",
    "cuda": "<version or cpu>",
    "device": "<hardware summary>"
  },
  "review": {
    "checks": ["prompt adherence", "artifacts", "license"],
    "known_failures": [],
    "limitations": []
  }
}

03 / Review each item before publication

Before publishing, check media and model licenses, personal data and likeness consent, checkpoint redistribution terms, synthetic-content disclosure, privacy leakage in prompts or sample data, and link accessibility. If checkpoint redistribution is not permitted, publish code, configuration notes, checksums and compliant samples only; keep sensitive media local.

• Can the inputs and processing be described without exposing private media?
• Can readers distinguish project code, instructional examples and proposed experiments?
• Are negative results, failures and scope retained instead of showing only the best-looking output?

Label material clearly as “run,” “instructional example” or “unverified,” and attach a checkable source or record to each claim.