Asset Provenance

1) Why filenames and folders do not prove provenance

Imagine a product image arrives from an agency as final-v7.png. A near-duplicate already exists in the DAM, another version has an AI-edited background, and the source license lives only in an email. Choosing the newest filename still does not tell us where the asset came from, what changed, who or what changed it, which hash or credential belongs to the current bytes, or whether rights and approval are valid for this version.

In this lesson we build Digital Asset Provenance Ledger v1: a bounded ledger that connects stable asset identity to sources and ingredients, activities, agents, hashes/credentials, rights/consent, approval and downstream use.

Central rule: provenance is evidence about history and binding. The presence of provenance or a valid credential does not automatically prove semantic truth, legal clearance or publication approval.

2) Scope boundary

COM-016 owns Asset Provenance. COM-015 owns the Single-source Content Model and COM-017 owns Content Workflow States. This lesson does not absorb either neighboring outcome.

It also performs no live use, legal clearance, billing change or production mutation. Fixtures are synthetic and decisions are bounded.

3) Mental model: Asset → Source/Ingredients → Activity/Agent → Binding/Credential → Rights/Approval → Downstream

For every asset version we should be able to answer: which asset and version; which source and ingredients; which activity occurred; which human/software agent acted; whether the current bytes match the recorded hash/binding; what the credential validation state is; what independent rights and consent evidence says; whether approval belongs to this exact version; and where the asset is used downstream.

If decisive evidence is unknown, disputed or stale, a success state is not allowed.

4) What W3C PROV provides—and what it does not

PROV-O models provenance using Entity, Activity and Agent plus relations such as generation, usage, derivation and attribution. This helps us separate source assets, transformation activities and responsible actors.

PROV-O is not a cryptographic signature of a media file. Recording a provenance relation does not by itself prove that bytes were not altered or that a legal claim is valid.

5) What C2PA Content Credentials add

C2PA 2.4 defines a C2PA Manifest containing assertions, a claim, a signature and content bindings. Derived and composed assets can preserve provenance through ingredient relationships. That gives stronger tamper-evident and content-binding evidence for media history.

But C2PA treats provenance as trust signals rather than an automatic value judgment about all content claims. Therefore credential_validation_state=VALID must not silently produce rights_state=APPROVED or approval_state=APPROVED.

6) Stable identity: separate asset_id and asset_version from filenames

asset_id is the logical identity; asset_version identifies a specific change. final-v7.png is a human label, not an identity contract. If bytes change while the old version and hash remain, the ledger must detect the mismatch.

A derived asset needs source_asset_ref; a composed asset needs complete ingredient_refs. Omitting an ingredient makes lineage incomplete even if the output file itself has a valid credential.

7) Activity and Agent: what happened, and who or what acted?

activity_id names the transformation: crop, color correction, generative fill, recomposition or export. agent_id records the actor; tool_or_model records the tool. Tool, agent and approval authority are separate concepts.

If an AI tool changes a background, that event belongs in the activity trace; the tool does not thereby grant rights or editorial approval.

8) Bind hashes and credentials to the correct version

content_hash must represent the bytes of the current asset_version. If the file was replaced but the old hash and credential state were retained, BLOCKED_HASH_MISMATCH is safer than success.

credential_ref and credential_validation_state must also be tied to the same version. Invalid, inaccessible or stale credential evidence stays visible rather than being normalized into success.

9) Rights, consent and approval are separate axes

A credential can validate while a license does not permit a new campaign. Rights may be clear while required consent is absent. Both may be fine while editorial approval became stale after a material transformation.

MAKNOW therefore keeps rights_state, consent_ref and approval_state distinct. Downstream use is allowed only when policy for that specific use is backed by adequate evidence.

10) Baseline example and counterexamples

In the baseline, the asset version is explicit, source and ingredients are complete, activity and agent are known, the hash matches, the credential is VALID, rights for the intended use are APPROVED, and approval applies to this exact version. The bounded state can be DOWNSTREAM_USE_ALLOWED.

Counterexample one: a composed asset has two declared ingredients but the ledger records only one. A valid credential on the composed output does not erase the missing lineage; result: BLOCKED_INGREDIENT_GAP.

Counterexample two: the credential validates but rights_state=UNKNOWN. The system may not infer rights approval from credential validity; result: BLOCKED_CREDENTIAL_OVERCLAIM.

11) Important failure modes

• Old hash after replacement: bytes changed while the old hash was retained → BLOCKED_HASH_MISMATCH.
• Derivative without source: a derivative has no source link → BLOCKED_SOURCE_LINK.
• Invalid credential: credential validation fails → BLOCKED_CREDENTIAL_INVALID.
• Stale approval: a material transformation creates a new version but approval still points to the old version → BLOCKED_APPROVAL.
• Missing decisive evidence: critical evidence is absent → HOLD_MISSING_EVIDENCE.

12) Lab and changed-context transfer

COM-016-LAB1 runs eight offline fixtures. The objective is to derive the state from visible evidence, not copy the baseline answer.

Transfer: a verified asset is cropped, color-corrected and combined with a new licensed ingredient. Create the new version, preserve source and ingredient links, record activity and agent, validate the new hash/credential context, and determine whether the previous approval still applies or fresh approval is required.

13) Bounded decision and freshness

This lesson produces a bounded downstream-use decision, not a universal truth judgment. If origin, ingredient set, hash, credential, rights or approval changes, recompute the decision.

Foundational reference: W3C PROV-O. Evolving reference: C2PA Content Credentials 2.4. Recheck C2PA version, validation and ingredient semantics by 2026-12-31 or earlier after a material specification change. BLOCK/HOLD rules, rights classes and approval transitions are MAKNOW design, not W3C or C2PA mandates.