Content Version Model and Derivative Lineage

1. Same content is not the same version

A stable content_id can have many immutable versions. Moving the master from CV-17 to CV-18 creates a new version; it does not rewrite CV-17. This is the foundation of auditability.

2. CON-012 ownership boundary

This lesson owns version and derivative lineage. CON-011 owns localization semantics, CON-013 owns calendar/campaign readiness, and C04 owns transform execution/QC. Here the question is: which exact version, parents and transformation produced this derivative?

3. Keep three identities separate

content_id is stable identity, content_version_id is an immutable snapshot, and derivative_id identifies a separate output with its own digest and lineage. A mutable latest pointer is only a lookup convenience.

4. PROV supplies derivation vocabulary

PROV-O models Entity, Activity, Agent and relationships such as wasDerivedFrom. MAKNOW uses that vocabulary for traceability, not as proof of rights or approval.

5. Derived asset is not a rendition

C2PA distinguishes editorial derived assets from non-editorial asset renditions such as re-encoding or scaling. A meaning change and a bitrate change therefore need different derivative classes.

6. A composed asset has multiple ingredients

A social image built from a master, logo and product image cannot be represented by one convenient parent. Decisive ingredients need explicit edges; a missing edge yields INCOMPLETE_LINEAGE.

7. Bind parents to exact versions

“Made from the master” is insufficient. Record CV-17 or an exact content binding/digest. When CV-18 appears, an old derivative must not silently become a child of CV-18.

8. Record transformation evidence separately

Capture the transformation action, recipe reference and, when relevant, a transformation digest. This explains generation but does not close rights or approval.

9. The derivative has its own byte identity

Every derivative carries its own digest. Equal filenames can hide different bytes and different filenames can contain identical bytes. Use exact version and digest evidence.

10. Upstream change never rewrites history

When the parent advances from CV-17 to CV-18, children of CV-17 remain historical children of CV-17. Policy may mark them STALE or REQUALIFY; do not repoint their old edges.

11. Staleness depends on derivative class

An editorial parent change often requires semantic derivatives to be requalified. A bitrate-only rendition can preserve the same editorial source version while creating a new rendition node and digest.

12. Rights and approval remain independent

A valid C2PA binding or complete PROV chain cannot resurrect revoked approval. Keep rights_check and approval_binding as independent graph dimensions.

13. Negative case: green provenance, red approval

If lineage validates but the parent-version approval is revoked, publication does not become valid. Emit REQUALIFY or BLOCK and record the exact reason.

14. Transfer with three mutations

Add a second ingredient to the social composition, create a resolution-only video rendition, and revoke one parent-version approval. Preserve old nodes and rebuild only new edges/states from fresh evidence.

15. Auditable output

Each row records Content ID, Version ID, Parent(s), Derivative ID/Type, Ingredients, Transform, digests, Rights, Approval, Stale state, Decision and Reason. The supported claim is reconstructability for this bounded fixture, not global truth, rights or publication authority.