Media Library: Hash, Rights, Variant, and QC

1. final.mp4 is not identity

A filename, folder, thumbnail, and latest-modified timestamp are useful lookup hints, not authority. Two files can have exactly the same name while containing different bytes. A media library must separate auditable identity from mutable labels.

2. The owned CON-014 boundary

CON-014 owns the media authority record: byte/digest identity, source/provenance, rights, variant lineage, and versioned QC. CON-015 owns reproducible recipes, CON-016 owns FFmpeg execution, CON-017 owns creative branching, and CON-018/CON-022 own publication gates and final media QA.

3. A digest is byte integrity/identity evidence only

asset_digest plus digest_algorithm binds exact bytes. RFC 9530 defines Content-Digest and Repr-Digest for integrity and explicitly does not define authentication, authorization, or privacy. A valid digest therefore does not establish reuse permission or semantic approval.

4. Separate Asset from Source Asset

media_asset_id identifies the current byte-bound record while source_asset_id identifies its source authority. If a filename stays constant but bytes change, create a new byte identity/digest record; overwriting history destroys provenance.

5. Provenance is a relationship, not a path guess

source_authority_ref and provenance_ref record where an asset came from and how it relates to another asset. C2PA 2.4 models ingredient relationships including parentOf, componentOf, and inputTo. That lineage does not by itself grant publication approval or every legal right.

6. Rights are an independent layer

Record rights_basis, rights_scope, and rights_expiry separately from digest and provenance. An asset can remain byte-identical and fully traced while its rights expire or become restricted. Identity stays stable while the decision changes.

7. A generic CC label is insufficient

Creative Commons licenses differ across BY, NC, ND, and SA conditions. A generic CC label cannot safely imply adaptation or commercial-reuse permission. Record the exact license/terms and applicable scope; this lesson does not provide legal advice.

8. Model variant lineage explicitly

Each variant_id needs a variant_role, parent, derivative relation, and transform_recipe_ref. A mobile rendition, proxy, and master are not interchangeable. Regenerating one branch does not silently invalidate unaffected siblings.

9. QC is not one green badge

Technical, semantic, rights, and aesthetic QC are separate evidence dimensions. A technical PASS cannot compensate for a semantic mismatch, rights failure, or aesthetic rejection. Bind each record to qc_record_id and qc_profile_version.

10. Keep staleness versioned and typed

A changed parent digest, rights event, or QC profile can make dependent evidence STALE. Historical evidence remains recorded; current state and recheck trigger change. UNKNOWN must not be converted into PASS for convenience.

11. The decision is about library authority only

LIBRARY_CURRENT means the library record is coherent for its exact scope and current evidence; it does not automatically make the asset publishable. RESTRICTED, BLOCK, and DEFER require an explicit reason and recheck trigger.

12. Build the matrix from independent signals

For each asset/variant, record byte binding, source/provenance, rights, lineage, and QC side by side. A valid decision cannot hide any critical dimension behind a filename, recency signal, thumbnail, or single badge.

13. Test tempting shortcuts deliberately

Reject three common shortcuts: “the newest file is authoritative,” “the digest matches so rights must be fine,” and “technical QC is green so publication is safe.” Each collapses one signal into a system-wide conclusion.

14. Lab: eight fixtures and 64 assertions

The lab includes baseline, same-name byte change, rights expiry, a fresh proxy, lineage mismatch, QC-profile drift, a generic CC label, and a mobile-only transfer. The evaluator checks eight independent outputs per case so state collapse becomes visible.

15. Transfer: new bytes, changed rights, mobile-only regeneration

In the transfer, the source is visually identical but byte-new, one rights grant expires, and only the mobile variant is regenerated. Rebuild the record so byte identity, rights state, parent lineage, and QC staleness change independently while unaffected siblings retain their own history.