7.4 Asset Management and Versioning

At a hundred assets the folder is fine. At ten thousand it is the thing that determines whether you can answer a question in a minute or a day — and the questions that arrive are not optional. Which model made this? What did we publish under version three? Can this be reproduced? Is this the same image we posted in March?

This chapter is the smallest system that answers those.

The library structure

Five axes, and the structure follows from the questions rather than from aesthetics:

assets/
  <persona>/                     one folder per persona
    00-bible/                    canon, timeline register (2.3, 2.4)
    10-references/               face, body, outfits, locations, props (5.3)
    20-datasets/                 training inputs (4.4)
    30-models/                   adapters, hashes, base version (4.5)
    40-prompt-lists/             variant files (5.2)
    50-output/                   raw generations, by run
      <run-id>/                  one folder per batch
        manifest.json            prompts, seeds, model, references
    60-approved/                 passed QA, not yet published (5.6)
    70-published/                what went out, when, where
    80-queue/                    fix queue and bank
    99-archive/                  retired versions, never overwritten

Three structural decisions worth defending.

A folder per run. Outputs are grouped by the batch that produced them, because that is the unit you will need to invalidate. If a run used a bad adapter, you want to identify everything it made, and that is a folder operation rather than a database query.

Approved and published are separate. The bank from 5.6 is approved-but-unpublished, and it is a different state from published. Merging them means you cannot tell what the audience has seen.

Archive, never delete. Retired references and adapters move to archive with their dates. Chapter 4.7's retirement procedure and 11.3's disclosure records both need the old versions to exist.

Asset status

Six states, and every asset is in exactly one:

Why statuses rather than folders alone. A status is a query. "How many approved assets do I have?" and "what has been approved for more than thirty days without publishing?" are questions that change decisions, and they are only answerable if the state is explicit.

The one status that needs discipline: rejected requires a defect code from 5.6's twelve-row table, not merely a flag. The codes are what turn the rejection history into a diagnosis of your pipeline — the difference between knowing your rejection rate is 30% and knowing it is 30% because of hands.

Metadata: the fields that earn their place

Per asset, with a reason for each:

Six of the sixteen exist for compliance. prompt, model, adapter, created, published_url, and disclosure_label are the fields that let you answer a regulator's or a platform's question about what you published and how it was made. Chapter 11.5's machine-readable marking obligations and 11.3's disclosure records depend on this data existing, and it cannot be reconstructed later.

The practical test: if a brand asks you to prove how a frame in an advertisement was produced, can you answer from the system in one minute? If not, a field is missing.

Automating the metadata

Manual metadata entry does not survive contact with volume. The system has to write it.

At generation time: the orchestrator (7.3) writes prompt, variant, seed, model version, adapter version, and reference paths into the run manifest. All of these are already known to the pipeline — this is a read-and-record step, not new work.

At QA time: the human adds the score and the status, which are the two fields that genuinely require judgement. Everything else was written already.

At publication time: the scheduler records the URL, the date, the platform, and the disclosure label. Again mechanical.

The consequence: the only fields a human touches are qa_score, defect_code, and status. Three fields, which is why the system is feasible.

Where to store it. A structured file per asset (JSON beside the image) or a database. A single JSON per asset survives tool changes, is greppable, and needs no infrastructure; a database is faster at scale and worse at portability. Start with files, and move when you have a query you cannot answer.

Deduplication and near-duplicate detection

Publishing the same frame twice is a specific failure with a specific cause: prompt variant lists get reused and the operator does not remember.

Two checks, both cheap:

Exact duplicates by hash. Trivial and catches the copy.

Near-duplicates by perceptually comparing a new asset against the last N published. An image hash or an embedding comparison catches the "same scene, slightly re-generated" case, which is the one that actually reaches the audience.

And a human check that no system replaces: does this feel like something we posted recently? Chapter 5.3's rolling exclusion rule is the manual version, and it is worth keeping even with automation, because a near-duplicate is a judgment about the audience's memory rather than a pixel comparison.

Versioning the assets themselves

Three separate version spaces, which people conflate:

Identity versions. LoRA v1, v2, v3, each with its base hash. Changing this changes the persona's face and is a major event (4.5, 4.7).

Reference versions. Sheet v1 for LoRA v1. A new sheet for the same adapter is a minor event (5.1).

Production versions. Prompt list 2026-Q3, graph version, preset version. Changing these changes how the same identity is rendered.

The rule: every asset records all three, because the answer to "why does this look different" depends on which space changed. An asset store that records only one cannot answer the question.

Backups

Unglamorous and mandatory, because the library is the business. Losing the reference library means losing the persona's ability to be reproduced.

Three copies, two media, one offsite. The classic formulation, and it holds here. A local drive, a second local copy on different hardware, and a cloud or remote copy.

Back up the references, adapters, prompt lists, and metadata first. These are small and irreplaceable. The generated outputs are large and regenerable, and they are the lowest-priority backup target.

Test a restore once. An untested backup is a file, as 3.6's hygiene rule says. Restoring one folder from your backup is a fifteen-minute exercise that proves the whole system.

Where this goes wrong

One flat folder. Unanswerable questions within months.

Merging approved and published. You lose track of what the audience has seen.

Deleting retired versions. You lose the ability to explain your own history.

Manual metadata. It will not be maintained.

Recording the model but not the base hash. The mismatch trap, undiagnosable.

No near-duplicate check. Repetition reaches the audience.

Conflating the three version spaces. "Why does this look different" becomes unanswerable.

No tested backup. The library is the business.

The gate

1. Does the library have one folder per persona with separate run, approved, published, and archive areas?
2. Is every asset in exactly one of six states?
3. Do you record the sixteen fields, including the six that exist for compliance?
4. Are metadata fields written automatically at generation and publication time, with only three fields touched by a human?
5. Do you have both an exact and a near-duplicate check?
6. Do you distinguish identity, reference, and production versions?
7. Do you have three copies, and have you tested a restore?

What you leave with

A five-axis library structure with a folder per run and separate approved and published states, six asset statuses with the discipline that rejections carry a defect code, sixteen metadata fields with the six that exist for compliance, an automation plan that reduces human entry to three fields, exact and near-duplicate detection, three version spaces that must be recorded separately, and a backup rule with one test.