Source Authority: Version Binding, Policy, and Reveal

1. The real problem: canonical does not prove an exact version

A URL, repository path, CMS row, or Drive file can be labeled “canonical” while the bytes beneath it silently change. If a consumer stores only the locator, it cannot later prove which version it consumed. This lesson builds Canonical Source Authority Record & Binding Matrix v1, separating stable canonical identity, exact immutable snapshot/version, digest and size, lineage, policy owner/version, reveal selectors, and consumer binding.

2. Separate three identities

canonical_source_id is the logical source identity; locator is only a resolution path; source_version or snapshot identity names the immutable version consumed. Never collapse these into one current_file field. A locator can move without changing canonical identity, and bytes can change beneath the same locator without remaining the same source version.

3. Binding must reach exact bytes

A version label alone is not enough. Record content_digest and content_size, then verify both when resolving content. OCI Descriptors are a useful pattern: content type, digest, and size travel together when referring to specific content. MAKNOW does not require OCI as its editorial format; it borrows the content-binding principle.

4. Model provenance lineage with PROV-O

PROV-O defines Entity, Activity, Agent, and relations such as wasDerivedFrom for provenance. Use the pattern to record source_version -> derived_from -> prior_version, responsible agents/owners, and generating activities. Provenance describes where a version came from; it does not choose MAKNOW canonical authority or reveal policy.

5. Preserve resolver history

If SRC-77 resolves to v3 today, that fact must not erase a historical consumer binding to v2. Keep resolver events append-only: when a canonical ID pointed to which snapshot, who changed it, and why. latest is a query over history, not the history itself.

6. Supersession is not invalidation

Version v2 can be superseded while its bytes, digest, and historical binding remain reproducible. Keep superseded_by=v3 separate from binding_verified. A new consumer may use v3 as current authority while an audit of an older decision still needs v2 exactly.

7. Type authority conflicts explicitly

If the registry resolves the canonical source to snapshot A while the declared digest identifies snapshot B, do not guess the newest or closest candidate. Emit AUTHORITY_CONFLICT and fail closed downstream. Never hide a conflict by overwriting one record.

8. UNBOUND_VERSION is a real state

When the path is unchanged but bytes change and the new digest has not been explicitly registered, do not silently call it the new canonical version. UNBOUND_VERSION means content exists but its exact authoritative binding has not been established. Existence is not authority.

9. Record policy identity and version separately

Every source decision should know the policy_id and policy_version under which it was made, plus policy owner and effective period. A policy change can alter consumption eligibility without changing source bytes, so policy state must remain separate from the source digest.

10. Reveal eligibility is an independent selector

Record reveal_after, audience_scope, and other selectors explicitly. A source can have a valid exact binding while the current public request is REVEAL_BLOCKED_TIME or REVEAL_BLOCKED_AUDIENCE. This lesson evaluates reveal as a policy selector; legal rights and embargo authority belong to CON-003.

11. Do not collapse binding and reveal into one flag

binding_verified=true does not authorize publication, and reveal_eligible=true does not prove that the bytes are the exact approved version. Keep two independent axes in the matrix: source binding state and reveal selector state. Downstream systems must consume them separately.

12. Bind consumers explicitly

Every claim, asset, or release consumer should store a consumer_ref and exact source_version_ref. If it stores only SRC-77 or faq.md, a resolver movement can silently rebind it. Explicit snapshot binding prevents hidden drift.

13. Rebinding is a new decision

When a new snapshot becomes canonical, do not automatically migrate existing consumers. Register and verify the new version, record supersession lineage, then emit an explicit rebind event containing actor, time, reason, and old/new bindings.

14. Transfer: the locator stays, authority changes

In the transfer case, faq.md keeps the same path while its bytes change; later the registry registers a new snapshot and the reveal audience changes. First emit UNBOUND_VERSION; after registration and verification, create an explicit new binding; then re-evaluate reveal selectors. Never copy the earlier state forward.

15. Final artifact and reliance boundary

Canonical Source Authority Record & Binding Matrix v1 stores Canonical Source ID, Locator, Source Version, Digest, Size, Provenance Entity/Activity/Agent, Derived From, Source Owner, Policy ID/Version, Reveal State/After/Audience, Superseded By, Binding Verified, Consumer Ref, Decision, Reason, and Rebind Trigger. This lesson does not score claim truth, determine rights, validate approval, or assemble release composition; it proves which exact source snapshot a consumer is bound to and whether the current reveal selector permits selecting it.