Chapter 21. Asset Approval, Naming, and Retirement#

21.1 An asset library is not a media folder#

A media folder answers where a file lives. An asset system also answers: what it is, who owns it, whether it is currently valid, what it may be used for, where it came from, who approved it, which shots reference it, and what a change would affect.

If a team dumps every generation result into "character references," failed faces enter the downstream context and the character drifts a little further with each pass. The first principle of governance is strict separation between candidates and golden assets.

21.2 The asset lifecycle#

Recommended states: exploration, candidate, review, approved, golden, locked, deprecated, retired, rejected.

approved means usable for a stated purpose. golden means usable as a generation anchor. locked means a change requires impact analysis. Not every attractive image earns golden status.

21.3 Let IDs and versions carry the naming#

Filenames are for humans to read; stable IDs are for the system to reference. Do not call a character lead_final_new2.png.

CH_LINYUN__FACE_FRONT_NEUTRAL__v003.png
WD_LINYUN_GREY_SUIT__FULLBODY_FRONT__v002.png
LOC_BOARDROOM_DAY__EMPTY_NORTH__v004.png
PROP_AUTHORIZATION__SIGNATURE_PAGE__v003.png
GRAPHIC_LEDGER_PAYMENT_01__zh-CN__v005.png

An asset ID does not change with the file version; versions increment and record their parent. Shots reference a specific version or an approved alias, so that overwriting a file cannot make a result unreproducible.

21.4 The asset record#

asset:
  id: CH_LINYUN_FACE
  type: character_identity
  version: 3
  status: golden
  files:
    - CH_LINYUN__FACE_FRONT_NEUTRAL__v003.png
    - CH_LINYUN__FACE_LEFT45__v003.png
  parent_version: 2
  purpose: identity anchor for Lin Yun
  allowed_use: [keyframe_generation, identity_qc]
  forbidden_use: [wardrobe_reference, lighting_reference]
  source:
    method: generated_and_human_retouch
    model_record: GEN_CHAR_0041
    retouch_record: EDIT_CHAR_0012
  rights_status: cleared_for_project
  approved_by: ART_DIRECTOR_01
  approved_at: 2026-07-04
  dependencies: []
  used_by: [E001_S01, E001_S03, E001_S08]

Recording provenance tells the team whether an asset is commercially usable, and supports reproduction.

21.5 Quarantine the candidates#

Exploration images live in a candidate area and, by default, cannot be read by the retrieval system, the prompt assembler, or downstream agents. Only an approval action promotes their state.

Rejected assets keep a thumbnail, a failure tag and a reason, which prevents repeating the same attempt — but they must never share a reference directory with the golden images. Failure tags include face-shape drift, profile failure, wrong perceived age, costume color bleed, deformed hands and unclear rights.

21.6 Approval is not "I like it"#

Each asset type has an acceptance sheet. Character identity is checked on structure, angles, age and differentiation. Costume is checked on pieces, materials and multiple angles. Locations are checked on geometry, lighting and reverse angles. Props are checked on scale, states and text. Audio is checked on timbre, pronunciation and emotional range.

Record conditional limits in the approval. A profile reference for one character may be usable in wides while being barred as an identity golden image. A vague approval produces incorrect use downstream.

21.7 Dependency graphs and change propagation#

Assets depend on each other. Character keyframes depend on identity, wardrobe and location. Video depends on keyframes. The edit depends on video and audio. Ads depend on the edit or on shots.

After the lapel on WD_LINYUN_GREY_SUIT changes, the system finds every keyframe and clip using that version. Exported shots do not all have to be redone; the owner grants waivers based on visibility, importance and continuity.

change_impact:
  change: WD_LINYUN_GREY_SUIT v2 -> v3
  reason: lapel structure inconsistent in the profile reference
  directly_affected: 46_keyframes
  downstream: 31_motion_clips, 3_episode_edits, 4_ads
  proposed_action:
    regenerate: 8_hero_closeups
    retouch: 11_medium_shots
    accept_with_waiver: 27_background_or_obscured

21.8 Locking and unlocking#

Assets lock before batch shot design or generation. Locking does not mean nothing can ever change; it means a change requires a change request carrying evidence of the problem, alternatives, scope of impact, budget, approver and the version from which it takes effect.

Emergency fixes must not overwrite the old file directly. Update the approved alias only after the new version is complete and sample regression passes.

21.9 Deprecation and retirement#

A deprecated asset can still support finished shots and may not be used for new ones. retired means the project no longer permits it at all. rejected never passed.

When a character enters a new age or wardrobe phase, the old assets do not necessarily retire — they may still serve flashbacks. Retirement must state the affected time range rather than deleting history.

21.10 Rights and the provenance chain#

Record source material, models, account licensing, human modification, fonts, music, likeness and the scope of permission. An asset with unclear provenance does not earn a waiver because it has been retouched heavily.

Classify reference images too: inspiration references never enter a model; licensed references may be used for generation; original approved project assets may go downstream. Never mix images found online into the same directory as approved assets.

21.11 Storage and verification#

Key files store a content hash, dimensions, color space and backup location, so that a same-named file cannot be silently substituted. Generation parameters and parent assets live in the metadata, not in a chat history.

Keep proxies separate from masters. Review can use compressed proxies; final generation and compositing reference masters. Moving a file never changes its asset ID.

21.12 Asset health audits#

Check regularly for: unreferenced assets, missing files, references to wrong versions, unapproved assets entering shots, expired rights, contradictory golden references, orphaned downstream files and duplicates.

The larger the project, the more asset debt behaves like code debt. Bypassing approval for short-term speed multiplies during batch generation.

21.13 SOP for asset governance#

First, establish types and stable IDs. Second, send all exploration results to quarantine. Third, run acceptance by type and record permitted uses. Fourth, approve a small number of golden assets. Fifth, generate the dependency graph after locking. Sixth, create a change request for any modification. Seventh, compute direct and downstream impact. Eighth, switch the alias after the new version passes regression. Ninth, deprecate without deleting history. Tenth, run asset health audits and rights reviews on a schedule.

21.14 Fault tree#

Symptom: the character looks less like herself over time. Candidates and failures are being retrieved as references. Quarantine assets and let only golden status enter prompts.

Symptom: nobody knows which file is final. Versions are managed in filenames and old files get overwritten. Use stable IDs, versions and approved aliases.

Symptom: one change causes errors everywhere in the cut. There is no dependency graph and no impact analysis. Freeze the release and compute downstream references.

Symptom: the assets are good and cannot be used commercially. Provenance and licensing were never checked at the approval gate. Make rights status a blocking field.

Symptom: the team is afraid to fix an obvious problem. Locking has been understood as prohibition. Establish a computable unlock and waiver process.

21.15 Checklist, exercises and deliverables#

Check that assets have stable IDs and versions; that candidates are quarantined; that golden images have explicit purposes; that approval is testable; that provenance and rights are complete; that dependencies are queryable; that changes carry impact analysis; that deprecated assets stop being used for new work; and that masters are hashed and backed up.

Exercise one: reorganize a chaotic media folder and assign IDs to twenty assets. Exercise two: simulate a change to a character's hairstyle and list every downstream impact. Exercise three: from ten candidates, approve three as golden, deprecate two, and write the reasons. Exercise four: determine the permitted scope of use for one reference image found online.

Deliverables for this chapter: the asset registry, naming rules, lifecycle states, approval records, the golden manifest, the dependency graph, change requests, the retirement log, rights provenance, and the asset health report.

21.16 Promotion must pass through explicit environments#

Assets pass through at least five environments: sandbox, candidate, approved, locked and deprecated. Sandbox allows fast exploration and cannot be referenced by production shots. Candidate has provenance and basic specifications and awaits stress testing. Approved is usable within a stated scope. Locked means a production batch currently depends on it and changes require a change request. Deprecated is readable only for historical work and rollbacks.

Figure 21-1 A candidate must carry evidence to be promoted to approved. Once an asset is depended on by shots and enters locked, changes trigger impact analysis. Deprecated preserves historical versions and the ability to roll back — it does not mean deleting the old files.

Approved and locked are not levels of quality; they are concurrency states. Approved can still be referenced by new tasks, while locked means a specific production batch depends on a specific version that must not be silently overwritten meanwhile. An asset can produce candidates on a new branch while the old approved version stays locked until the migration completes.

Promotion is not moving a folder. It changes the registry state and attaches evidence. A character candidate needs multi-angle pass records; music needs a licence and stems; a location needs empty plates and a floor plan; a text template needs phone legibility tests. Missing any blocking evidence, the system refuses promotion — however much the creative lead likes it.

Urgent production may create a time-limited provisional approval, which must state the applicable shots, the risk, the expiry and the reviewer. A provisional approval must not quietly become the season default; once it expires, any dependent shots without supporting evidence enter the risk queue automatically.

21.17 Content hashes, immutable versions and reproducibility#

An identical filename does not prove identical content. Every approved asset stores a content hash, the creating tool and version, the prompt or source, its reference dependencies and key parameters. Downstream shots record the hash actually used, not merely character_front_v3.png. If someone overwrites the original file, verification fails immediately.

Immutable versions do not obstruct iteration. A change produces v04 and both versions coexist; the alias latest_approved can point to v04 while locked shots still point at the specific hash of v03. Rebuilding a historical shot then cannot accidentally use a future version, and the scope of an upgrade can be computed exactly.

Where an external service cannot fully reproduce a generation, the approved file itself is the authoritative artifact. Storing the seed and parameters helps with retries but does not replace the original high-quality file, its metadata and a verified copy. The minimum standard for reproducibility is being able to prove what was used — not necessarily producing pixel-identical output on a rerun.

21.18 Permissions, leases and concurrent edits#

The asset system distinguishes read, propose, approve, publish and retire permissions. An agent may create candidates and difference reports and may not overwrite a golden identity. An art director may approve visual assets and may not confirm a music licence on legal's behalf. A producer may freeze a batch and may not change story facts. Permission boundaries let automation stay fast without exceeding its authority.

When several people work at once, use editing leases: once an asset enters a modification state, other tasks read the previously approved version and cannot submit a conflicting new one simultaneously. Leases release automatically on timeout and unfinished candidates stay in sandbox. Text and structured data can merge at field level; images and audio usually branch by version and are chosen by a human.

Every approval and retirement writes an audit event containing operator, time, justification and scope of impact. When a commercial project is disputed, the team can answer why a shot used a particular voice, who confirmed the licence and when a character image was replaced — rather than searching chat logs and guessing.

A note on sources#

An asset library is common advice in AI comic-drama practice, but assets only become production memory once governance, versioning and dependencies exist. This chapter raises media management into an auditable system, providing the foundation for the continuity and agentic orchestration chapters that follow.