Fidelity and the absence asymmetry
Why can lineage prove a dependency exists but never that one does not?
Fidelity, and the asymmetry that matters most
Lineage is routinely used to make negative claims:
- "Nothing else reads this table, so it is safe to delete."
- "No sensitive column flows into this dataset, so it is safe to share."
Negative claims need completeness. Lineage is systematically incomplete, by construction, for the coverage reasons above. So the honest description is:
Nearly every tool presents lineage as both sound and complete. The practical result: deletions justified by lineage break things that lineage could not see. (This is Priya's audit problem, and it is the same logic: an absent edge was read as an absent dependency.)
The escape: a mandatory channel
The escape is not better lineage. It is to stop making absence claims from observation and to create a channel that everything must pass through. Options:
- revoke access and log the denials, so a hidden user shows up as a failed request;
- stop serving the asset and see who complains;
- route all reads through a proxy that must be used.
This turns "I observed no usage" into "usage is now impossible without telling me." It is the write-audit-publish pattern applied to deletion (check before you commit), and it generalizes into one of metadata's few real escapes.
Lineage can prove a dependency exists. It can never prove one does not. Deprecation built on the second reading is how tables get deleted out from under quarterly reports.