{"slug": "recording-generated-asset-provenance-originals-and-selection-decisions", "title": "Recording generated-asset provenance, originals, and selection decisions", "summary": "A developer audited the AI-generated asset pipeline in the game-jam-lab repository at commit f074703, documenting how a review-manifest.json links candidate IDs to generation parameters, reference files, Codex reviews, and human review decisions. The inspection script found all 107 candidates marked as generated, with 35 approved, 13 on hold, 3 rejected, and 56 unreviewed, and identified three defeat-effect candidates that the game code preloads despite their humanReview.status remaining unreviewed. The audit also notes that the manifest's recorded original file differs from the processed cutout the game actually loads, and that null seeds mean identical regeneration cannot be assumed.", "body_md": "Generating assets with AI also produces candidates that never get used. Saving only the images makes it harder to reconstruct the references used, whether a person approved a candidate, and which processed file the game actually loads.\n\nA stable candidate ID can connect the original, generation parameters, reviews, and code references while keeping those checks separate. This article examines VOLT NOMAD's asset records, including a place where the recorded states do not agree.\n\nThe investigation took place on September 11, 2026, against `game-jam-lab` commit `f074703`. It did not call generation APIs or create new images.\n\nThe repository contains [ASSET_PROVENANCE.md](https://github.com/takahiro-saeki/game-jam-lab/blob/f074703848586828b6a5acc0e465ccdd2c0d5244/events/2026-ai-browser-game-jam-4/docs/ASSET_PROVENANCE.md), which explains the production process, and [review-manifest.json](https://github.com/takahiro-saeki/game-jam-lab/blob/f074703848586828b6a5acc0e465ccdd2c0d5244/events/2026-ai-browser-game-jam-4/tools/art-review/data/review-manifest.json), which records individual candidates.\n\nThe document describes where generation and processing were used. The manifest groups candidates into generation batches and stores information such as:\n\n| Record | What it lets you inspect | \n|---|---|\n| `id` ,`file` | Candidate identity and the original file | \n| `prompt` ,`model` , dimensions,`seed` | Recorded generation parameters | \n| `referenceFile` , where present | The reference image | \n| `generation` | Generation status, timestamp, usage, and errors | \n| `codexReview` | Recommendations and concerns | \n| `humanReview` | Human decisions, ratings, and review timestamps | \n\nThis structure separates successful generation from a selection decision. Some candidates have a `null` seed, so the existence of a manifest does not establish that an identical image can be regenerated.\n\nConsider `final-fallen-machine-seraph-v9-c`. A reduced excerpt of its recorded values is:\n\n```\n{\n  \"id\": \"final-fallen-machine-seraph-v9-c\",\n  \"model\": \"pixen\",\n  \"seed\": null,\n  \"file\": \"source/enemy/final-fallen-machine-seraph-v9-c.png\",\n  \"codexReview\": {\n    \"status\": \"recommended\",\n    \"score\": 98\n  },\n  \"humanReview\": {\n    \"status\": \"approved\",\n    \"rating\": 5\n  }\n}\n```\n\nThe full record also includes the generation timestamp, prompt, recommendation rationale, and human review notes. The values 98 and 5 are ratings stored in the manifest, not image-quality or performance measurements made in this investigation.\n\nThe provenance document describes removing the original's background to produce a cutout for the game. In the [game code](https://github.com/takahiro-saeki/game-jam-lab/blob/f074703848586828b6a5acc0e465ccdd2c0d5244/events/2026-ai-browser-game-jam-4/godot/games/charge_clicker/charge_clicker.gd), `prime_current_form_3` preloads `final-fallen-machine-seraph-v9-c-cutout.png`.\n\nThe manifest's `file` therefore differs from the file loaded by the game. SHA-256 hashes of the original and cutout at the fixed commit also confirm different byte contents. A hash difference does not explain the transformation, but the document and code reference together establish a traceable relationship between original and processed file.\n\nThe [inspection script](https://github.com/takahiro-saeki/articles/blob/codex/article-stock-2026-09/experiments/article-stock-2026-09/game-submission-evidence.mjs) reads the manifest and file listing from the fixed commit. On Node.js `v24.15.0`, it found:\n\n`file` entries.`generation.status` set to `generated` for all 107 candidates.`approved` for 35, `hold` for 13, `rejected` for 3, and `unreviewed` for 56 candidates.\nThese are checks of records and original-file presence. They are not a visual evaluation of 107 images or evidence that all 107 entered the game.\n\nThe following 3 defeat-effect candidates were preloaded by the game code while their `humanReview.status` remained `unreviewed`:\n\n```\nFracture: defeat-vfx-core-fracture-v12-a\nHalo: defeat-vfx-voltage-halo-v12-b\nShards: defeat-vfx-machine-shards-v12-c\n```\n\nAn `approved` filter alone therefore cannot produce the complete list of implementation references. However, an unreviewed record does not prove that no person ever looked at an image. The supported finding is narrower: human approval was not recorded in the manifest at that revision, and a code reference existed.\n\nThe repository already separates generation status, AI recommendations, and human decisions. The inspected manifest did not provide a uniform per-candidate structure recording the runtime file through which each candidate was integrated.\n\nOne possible addition would record usage separately, rather than forcing every review status to `approved`:\n\n```\nCandidate ID\n  ├ Original path and hash\n  ├ Human decision and rationale\n  └ Usage\n      ├ Processed-file path and hash\n      ├ Document or script describing the transformation\n      └ Code commit in which the reference was verified\n```\n\nThis is a future design proposal. It was not added to the existing manifest.\n\nAn empty usage record should not immediately mean “unused”; usage might simply be undocumented. Similarly, finding a code reference does not prove that the asset always appears during normal play. This investigation performed static reference checks, not a fresh visual run of the game.\n\nTo replace the final-form image, first identify the candidate and original, read the selection rationale, and follow the processed file into the code. Overwriting only the original may leave the display unchanged if the game still references the cutout.\n\nReplacing only the processed file can make its relationship with the original unclear. Decide whether the new file is a new candidate or another derivative of the same candidate, then record that relationship.\n\nThis investigation could trace candidate IDs to originals and reviews, then use the document and code to locate processed-file usage. It also found examples where human approval records and code references differed.\n\nKeep generation, judgment, and usage as separate records rather than reducing them to a single “adopted” flag. When replacing an asset, use those records to check the relationship between its original and its usage.", "url": "https://wpnews.pro/news/recording-generated-asset-provenance-originals-and-selection-decisions", "canonical_source": "https://dev.to/hirodeath/recording-generated-asset-provenance-originals-and-selection-decisions-3p0a", "published_at": "2026-09-30 02:36:26+00:00", "updated_at": "2026-09-30 02:46:44.180983+00:00", "lang": "en", "topics": ["ai-tools", "generative-ai", "developer-tools"], "entities": ["game-jam-lab", "VOLT NOMAD", "takahiro-saeki", "pixen", "Node.js", "final-fallen-machine-seraph-v9-c"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/recording-generated-asset-provenance-originals-and-selection-decisions", "markdown": "https://wpnews.pro/news/recording-generated-asset-provenance-originals-and-selection-decisions.md", "text": "https://wpnews.pro/news/recording-generated-asset-provenance-originals-and-selection-decisions.txt", "jsonld": "https://wpnews.pro/news/recording-generated-asset-provenance-originals-and-selection-decisions.jsonld"}}