Data rights belong in lineage, not legal footnotes

I believe data rights belong in lineage, not in legal footnotes. A licence, consent record, purpose restriction, residency rule, or deletion obligation that sits in a contract repository cannot govern a pipeline. It cannot stop a prohibited join, prevent a training run, constrain an agent’s tool call, or identify the models affected by a withdrawal. If a right is meant to change what engineers and machines may do with data, the platform must carry it beside the data and evaluate it where the data moves.

I would start at ingestion with a versioned rights manifest for every source. The record needs more than an owner and a licence label—it needs a stable source identifier, content hash, acquisition time, rights holder, lawful basis, permitted purposes, commercial-use and sublicensing terms, attribution requirements, allowed jurisdictions, retention limit, expiry, opt-out status, and the evidence behind each assertion. “Unknown” must be a real state, not an empty field interpreted as permission. Content-addressing matters because the same work can arrive through several URLs; deleting one acquisition record while an identical hash remains elsewhere is not deletion.

Those manifests become useful only when attached to a lineage graph. Source documents flow through cleaning, deduplication, merging, chunking, synthetic generation, fine-tuning, evaluation, model registration, retrieval, and agent-produced artifacts. Every edge should record the transformation and every output should retain references to its inputs. Rights then propagate forward as constraints. A transformation may make a restriction tighter, but it should not silently make it looser. Combining two datasets should normally produce the intersection of their permitted uses, not the most convenient interpretation of either licence.

That changes governance from retrospective reporting into admission control. Ingestion checks machine-readable opt-outs and approved-source policy before accepting content. Transformation jobs reject incompatible purposes or jurisdictions. Training orchestration resolves the applicable rights set before allocating compute. Model promotion checks whether the dataset snapshot and its attestations are complete. At runtime, retrieval and agent gateways carry classification, purpose, retention, no-log, and location constraints into delegated work. I want the system to fail closed on absent evidence because uncertainty is itself a governance state.

Lineage also makes revocation operational. When consent is withdrawn, a licence expires, a vendor issues a deletion notice, or a source is found to be unlawfully acquired, the platform should traverse forward from the affected hashes. It can quarantine derived datasets, block new training and retrieval, identify deployed models and generated artifacts, open remediation work, and preserve signed evidence of each action. The graph exposes rather than solves the separate model-remediation problem: selective removal from weights remains technically difficult. What it supplies is the actual blast radius and the control needed to prevent the next generation from repeating the violation.

This is even more important when agents cross organizational boundaries. A final report may depend on customer records, licensed research, intermediate summaries, and transformations performed by several agents in different jurisdictions. Its provenance needs to say which entity was used, which activity transformed it, which agent acted, under what delegated authority, where processing occurred, and which governance envelope was in force. Constraints must travel into sub-tasks and may become stricter, never weaker. Otherwise each participant can produce a clean local audit while the end-to-end artifact remains legally unintelligible.

My precise concession is that some rights cannot be reduced to a deterministic policy field. Fair-use analysis, compatibility of a new purpose, and conflicting jurisdictional claims can require facts, interpretation, and legal judgment. In those cases the lineage system should route an explicitly ambiguous claim to review rather than pretend to decide law. The boundary is narrow: judgment determines the applicable constraint; once determined, the constraint, evidence, scope, and review date still belong in machine-readable lineage.

I treat this as a data-platform responsibility because the platform already controls movement, derivation, versioning, and access. Putting rights in lineage gives legal teams queryable evidence, gives engineers executable constraints, and gives operators a map for impact analysis and remediation. It also improves the data product itself: consumers can know not only where an asset came from, but what they are allowed to do with it. A footnote can explain a right. Only lineage can make that right survive the pipeline.