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 raises volume by an order of magnitude while making that metadata 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 it at creation costs minutes; reconstructing it later is usually impossible.
Key takeaways
- A usable AI content library needs five metadata groups per asset: lineage, rights, review, depiction and publication status.
- Generative production breaks conventional asset management because volume, provenance, rights and review status all change from project-level to per-asset properties.
- Derivatives should be tracked as a parent-linked graph, not as file versions, so a correction to a master can be propagated to every published descendant.
- The only reliable way to keep metadata populated is to block publication when required fields are missing, since optional fields go unfilled within weeks.
- The fastest audit of an existing library is sampling 20 assets at random and trying to answer "can we reuse this, here, now?" from the record alone.
Why does generative production break asset management?
Conventional libraries were built around scarcity, where a shoot produced a known set of assets and one rights position covered the whole project. Generative production removes every one of those assumptions at once.
- 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, and 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 for an AI content library?
The schema needs seven field groups covering identity, lineage, rights, review, depiction, publication and lifecycle, each answering a question a reuse decision depends on. Provenance metadata is the record of how an asset was generated — model, version, references and brief — kept separately from the file because most distribution paths strip it out.
| 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 |
Descriptive standards such as IPTC for photo metadata and C2PA for embedded provenance are worth adopting where the pipeline supports them, but they are a bonus, not a substitute. Rights and depiction are the two groups most often omitted, because neither is needed on the day the asset ships, and they are exactly the two that turn a library from storage into a reusable asset base. One design decision matters more than the schema itself: the system record is authoritative, not the file, because a stable asset ID keyed record is what survives transcoding and platform re-uploads while embedded metadata does not.
How do you version a derivation graph instead of a file?
Version control built for one file at a time — v1, v2, v3 — does not describe generative production, where an approved master spawns many derivatives that are not versions of each other. A derivation graph is a record structure where every derivative asset carries a link to its parent asset, so a change to the parent can be traced forward to everything descended from it.
| 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, turning a correction into a work item instead of a hope. Takes are a judgement call — keep them when regeneration is expensive and they are clearly flagged as unselected, delete them when 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 day to day?
Six 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, testing whether the reuse question is answerable from the record alone.
That last routine yields the metric worth reporting upward: the library reuse rate, calculated as sampled assets whose reuse question is answerable from the record divided by assets sampled. It is usually lower than expected, and 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.
What is the reuse question, and why does it matter?
Everything in the schema exists to make one question answerable in minutes: can we use this asset, in this market, for this purpose, now? Five sub-questions decide the answer, each pulling from one part of the record.
- 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 states 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.
Without a record, the answer defaults to regenerating the asset, because clearing it is harder than producing it again. That is a defensible individual decision that, repeated across every campaign, means the library never becomes an asset and every campaign costs what the first one cost.
How does Lifewood approach AI content asset management?
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. A delivery batch spanning 50+ languages and several markets cannot be cleared for reuse any other way. This schema is deliberately the one a client should hold any vendor to, including Lifewood, because 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, which pairs with the quality-control checks that populate the review field group and the provenance standards referenced above. Teams writing the brief that feeds an asset's lineage field can also see how to write a brief an AIGC team can produce from, and localisation teams generating the language-variant nodes in the derivation graph should see localizing one video into 50 languages. Managed delivery of the underlying video assets is covered under AIGC services and AIGC video production.