Portfolio Metadata Control without Content Copy

Owned boundary and outcome

This lesson produces Portfolio Metadata Reference & Provenance Registry v1. It creates a central metadata/control catalog without copying the canonical content body into spreadsheets, CMS records or venture repositories. Canonical ownership stays with the source system.

Problem to solve

Copying titles, claims, assets or source text for “central control” quickly creates a second source of truth. Version, rights, provenance and lifecycle then drift between the copy and source, and the team can no longer prove which record points to the current resource.

FACT and DESIGN boundary

RFC 3986 supplies an identifier pattern, OCI demonstrates reference-plus-digest evidence, and W3C PROV models attribution, versioning and derivation. None of these standards defines MAKNOW no-copy governance or registry states; those are local design choices.

Registry evidence contract

Each row records portfolio item ID, canonical resource ID/URI, digest, version, source system/owner, rights, provenance, copy policy, reference health, digest verification, freshness, last verified and evidence reference. The canonical body is not stored in the registry.

Control states

VERIFIED requires a healthy reference, matching digest/version, clear rights and provenance, and fresh metadata. STALE covers mismatch or old verification; BROKEN covers deleted/unresolvable sources; DISPUTED covers rights/provenance conflict; HOLD, PARTIAL and BLOCKED preserve incomplete or prohibited states.

Primary registry

The table keeps metadata and evidence together without copying the canonical body.

Defensible baseline

A metadata row that points to a resolvable canonical URI, matches the current digest/version, has known provenance and rights, and uses REFERENCE_ONLY policy is VERIFIED. This state is about reference and evidence health, not a quality judgment on the content itself.

Digest mismatch

If the URI stays the same while bytes change, the old row must not remain VERIFIED. Digest mismatch moves the row to STALE until version and evidence are refreshed through an authorized path.

Broken reference

If the canonical resource is deleted or the reference no longer resolves, old metadata does not prove the content still exists. The state becomes BROKEN and a retention, replacement or escalation path is required.

Rights and provenance

A rights change or unknown source owner can constrain venture use even when the digest matches. Provenance and rights are independent from reference health and should not collapse into one boolean.

Execution workflow

1. Record canonical ID and URI. 2) Capture version/digest from source. 3) Record source owner and provenance. 4) Evaluate rights and venture usage. 5) Keep copy policy REFERENCE_ONLY. 6) Verify reference and digest. 7) Record freshness and last-verified time, then assign state.

Offline lab

The lab contains eight synthetic fixtures. Each checks eight deterministic outputs: state, reason, reference OK, digest OK, rights OK, provenance OK, missing-critical count and recompute-required. No network or live repository is needed.

Transfer

If one canonical asset changes bytes at the same URI, another is deleted and a third changes rights state, the registry must independently move rows to STALE, BROKEN or an authorized update path. Each row is recomputed independently from changed evidence; one changed resource does not automatically change unrelated rows.

Assessment

You must explain the no-copy boundary, build the baseline registry, diagnose digest mismatch and broken reference, and rebuild the transfer case with three independent source changes.

Review and lifecycle

Each row carries last-verified and freshness evidence. Byte changes, resource deletion, rights change, provenance change or reference failure trigger review. VERIFIED should fail closed when decisive evidence is stale or conflicting.