Short answer. Record, per asset, the five things that cannot be reconstructed later: how it was made, what rights attach, what review it received, what it depicts, and where it has been published. Generative production changes the asset-management problem in one specific way — volume rises by an order of magnitude while the metadata that makes an asset safely reusable becomes both more necessary and easier to lose. The result is libraries full of files nobody dares reuse, because nobody can establish which model made them, whose consent covered them, or whether they were ever reviewed. Recording that at creation costs minutes; reconstructing it is usually impossible, which means the asset is effectively lost while still occupying storage.
The symptom to watch for is specific. Someone asks whether an existing asset can be used in a new market, and the answer takes a week or comes back "we had better make a new one". At that point the library has stopped being an asset and become storage.
That is a metadata failure rather than a search failure, and no amount of better tooling fixes it retroactively. This guide covers why generative production breaks the conventional model, the minimum schema that prevents it, how to version a derivation graph, and how to test what an existing library is actually worth.
Why does generative production break asset management?
Conventional libraries were built around scarcity. A shoot produced a known set of assets, the rights position was established once for the shoot, and a person could hold most of the inventory in their head. Every one of those assumptions fails.
- Volume rises by an order of magnitude, including takes that were considered, rejected and never deleted.
- Provenance becomes a question. Which model, which version, which references, which brief — none of it is visible in the file, and all of it matters later.
- Rights become per-asset rather than per-project. Different assets in one campaign may use different models under different terms, and different consents with different expiry dates.
- Review status becomes a property of the asset. Some were fully reviewed, some sampled, some never reached. Without a record they all look identical.
- Variants multiply. One master becomes fifty language versions across several aspect ratios, and a correction to the master has to find all of them.
What is the minimum metadata schema?
Descriptive standards already exist — IPTC for photo metadata, C2PA for embedded provenance — and are worth adopting where the pipeline supports them. The fields below are orthogonal to those: they are the ones specific to generative production that decide whether an asset can be safely reused.
| Field group | What to record | The question it answers |
|---|---|---|
| Identity | Stable asset ID, human-readable name, asset type, created date | Which file is this, unambiguously, across every system |
| Lineage | Model and version, provider, generation date, references used, brief or prompt reference, parent asset ID | How was this made, and can it be regenerated or corrected |
| Rights | Model terms version, licences for incorporated assets, consents held with scope and expiry, cleared markets | May we use this, here, now |
| Review | Reviewer, rubric version, date, sample or full, errors found, disposition | Has anyone actually checked this |
| Depiction | Real people, places, brands or events appearing; whether synthetic; labels applied | Does this trigger disclosure or consent duties |
| Publication | Where published, when, which variant, current status | What is live, and what needs correcting if the master changes |
| Lifecycle | Review-by date, expiry, retention class, supersedes / superseded-by | Should this still be in circulation |
The rights and depiction groups are what turn a library from storage into a reusable asset base, and they are the two most often omitted — because neither is needed on the day the asset ships.
One further design decision matters more than the schema itself: the system record is authoritative, not the file. Most transcodes and platform uploads strip embedded metadata, so a record keyed to a stable asset ID is what survives. Embedded C2PA credentials and IPTC fields are a useful bonus that survives some distribution paths and not others.
Versioning a derivation graph, not a file
The conventional model — v1, v2, v3 of one file — does not describe generative production, where an approved master spawns many derivatives that are not versions of each other. What is needed is a graph, and its essential property is that every derivative knows its parent.
| Node | What it is | Review position |
|---|---|---|
| Master | The approved source: locked picture, live text layers, separated audio stems | Fully reviewed |
| Language variant | Derived from the master, one per market | Its own review record, because a different person reviewed it in a different market |
| Format variant | Aspect ratios, durations, platform cuts, derived from a language variant | Usually not separately reviewed for content |
| Correction | A new master version that must propagate downward | Re-reviewed, and every published descendant dispositioned |
| Take | A generated candidate that was not selected | Never approved, and must never surface as though it were |
The propagation rule is what makes the graph worth maintaining: when a master changes, the system should be able to list every published derivative, so a correction becomes a work item rather than a hope. Organisations that discover they cannot produce that list usually discover it during a legal or factual correction, under time pressure.
Takes are a judgement call. Keep them if regeneration is expensive and they are clearly flagged as unselected; delete them if storage and search noise cost more than regeneration would. What is not defensible is keeping them unmarked, where they eventually get mistaken for approved output.
How do you operate the library?
These routines keep the schema honest. Without them it decays into optional fields nobody fills in.
- Capture metadata at creation, automatically. Model, version, references and brief reference should be written by the pipeline, not typed afterwards. Anything requiring manual entry after the asset ships will be missing on a meaningful share of assets within a month.
- Block publication on missing required fields. Rights position, review record and depiction record are required for release. A gate at publication is the only mechanism that reliably keeps them populated, and it is far cheaper than an audit later.
- Track expiry actively. Consent terms, licence terms and factual review-by dates all carry dates. Run a scheduled report and act on it — an expired consent on a published asset is a live exposure, not a filing issue.
- Propagate corrections through the graph. When a master changes, list every published derivative and disposition each one: update, withdraw, or accept as-is with a recorded reason.
- Prune on a schedule. Unselected takes, superseded variants, and assets that can no longer be cleared. A library that only grows becomes unsearchable and accumulates exactly the assets that create risk.
- Audit a sample quarterly. Twenty assets at random, and try to answer the reuse question from the record alone.
That last routine yields the only library metric worth reporting upward:
Library reuse rate = Sampled assets whose reuse question is answerable from the record ÷ Assets sampled
It is usually lower than expected, and it is a far better measure of what a library is worth than asset count or storage volume, both of which improve as the library gets worse.
The reuse question, which is the whole point
Everything above exists to make one question answerable in minutes: can we use this asset, in this market, for this purpose, now? Working through it shows why each field group earns its place.
- Do we have rights? Model terms permitting this use, licences for incorporated assets, and consent from anyone depicted — still in term, and covering this territory.
- Is it accurate? The review record shows it was checked, the factual review-by date has not passed, and nothing it asserts has since changed.
- Is it compliant here? Labels and disclosures required by this market are present, and the depiction record says whether any are triggered at all.
- Is it current? Not superseded by a later master, and consistent with current brand and product reality.
- Is it right for this market? Reviewed by someone in-market, or explicitly flagged as not yet assessed.
Five questions, all answerable from the record if the record exists. The alternative — regenerate, because clearing is harder than producing — is a defensible individual decision that, repeated, means the library never becomes an asset and every campaign costs what the first one cost.
How Lifewood approaches this
Lifewood maintains asset-level records across AIGC deliveries — model and version, references used, rights and consent scope with expiry, review record with reviewer and rubric, labels applied, and publication destinations — because a delivery batch spanning 50+ languages and several markets cannot be cleared for reuse any other way. The schema published above is deliberately the one a client should hold any vendor to, this one included: it is more useful as a specification a buyer can enforce than as a proprietary detail.
For the compliance side of the same record — what provenance must contain and how disclosure positions are set — see AI content governance, disclosure and provenance, alongside AIGC services and AIGC video production.
Sources and further reading
- C2PA and Content Credentials Explainer, specification 2.4 — Coalition for Content Provenance and Authenticity, April 2026.
- IPTC Photo Metadata Standard — International Press Telecommunications Council.
- Copyright and Artificial Intelligence, Part 2: Copyrightability — U.S. Copyright Office, January 2025, on human contribution and records.
- Article 50, Transparency Obligations — EU Artificial Intelligence Act (consolidated text).
- AI Risk Management Framework (AI RMF 1.0) — National Institute of Standards and Technology, January 2023, on traceability and documentation.