Skip to content
Mehridian
Search published pages · Ctrl/Cmd + K

Lineage and provenance — evidence binding

1 min read

In one line

Why repository relations and partial byte checks differ from exact-candidate lineage.

Three claims can sound similar while requiring different evidence.

Repository relationship: a public projection can be related to a source repository. A recorded projection_of relationship is useful, but does not automatically bind every file to an exact source candidate.

Scoped provenance: a declared subset can be checked precisely. Consumer Lab’s frozen record establishes provenance for 27 manifest-declared files whose source and target blob identities matched. The subset is part of the result, not a detail that can be dropped.

Whole exact candidate lineage: the stronger claim binds the whole candidate across the source-to-target path. In Project 03, this remained NOT_ESTABLISHED for all 15 repositories, including Consumer Lab. That is not proof that all relationships or all provenance were absent.

The concept connects to Evidence verification: name the claim and the scope before choosing the check. It also matters in Edge Evidence, where content fingerprints and receipts must not be confused with approval or a universal source-to-deployment identity proof.

The stronger claim would need evidence binding the whole exact candidate, not merely those files.

Research basis: original connected Project 03 story/concept and frozen schema-v1.1 comparison. Exact private tab, range, screenshot and claim pointers are retained in the internal review matrix; no source-workbook links are published.

Where this note sits

Verification and provenance · 5 linked pages

Graph View

Linked from

All notes, on one map →