Use this issue to track InQL RFC 030, proposed in PR #60 at docs/rfcs/030_prism_lineage_graph.md.
Area
- Specification (RFCs)
- Documentation
Summary
RFC 030 defines a Prism lineage graph for InQL relational evidence. It describes how authored and rewritten Prism plans expose field lineage, expression lineage, aggregate/window/generator relationships, read-root origins, and rewrite provenance using stable semantic targets.
Motivation
InQL can already express typed relational plans, but tools need a trustworthy local way to answer where an output field came from and which transformations affected it. If each consumer reconstructs lineage from Substrait or backend plans, lineage will drift from InQL's authored semantics.
Proposal sketch
Define lineage nodes and edges over semantic targets produced by Prism. The graph should preserve authored-origin relationships through rewrites and should distinguish value lineage from client-origin references, backend diagnostics, and execution observations.
Alternatives considered
The draft rejects reconstructing lineage from backend plans, using only Substrait metadata, and treating display names as lineage identities.
Impact / compatibility
This is additive. Existing plans remain executable without lineage artifacts. Inspection APIs should report missing lineage support explicitly rather than inferring partial lineage from names.
Implementation notes (optional)
Review PR #60 for the draft. This RFC depends on RFC 028 semantic targets and feeds inspection, bundles, plan diffs, governance, and export bridges.
Checklist
Use this issue to track InQL RFC 030, proposed in PR #60 at
docs/rfcs/030_prism_lineage_graph.md.Area
Summary
RFC 030 defines a Prism lineage graph for InQL relational evidence. It describes how authored and rewritten Prism plans expose field lineage, expression lineage, aggregate/window/generator relationships, read-root origins, and rewrite provenance using stable semantic targets.
Motivation
InQL can already express typed relational plans, but tools need a trustworthy local way to answer where an output field came from and which transformations affected it. If each consumer reconstructs lineage from Substrait or backend plans, lineage will drift from InQL's authored semantics.
Proposal sketch
Define lineage nodes and edges over semantic targets produced by Prism. The graph should preserve authored-origin relationships through rewrites and should distinguish value lineage from client-origin references, backend diagnostics, and execution observations.
Alternatives considered
The draft rejects reconstructing lineage from backend plans, using only Substrait metadata, and treating display names as lineage identities.
Impact / compatibility
This is additive. Existing plans remain executable without lineage artifacts. Inspection APIs should report missing lineage support explicitly rather than inferring partial lineage from names.
Implementation notes (optional)
Review PR #60 for the draft. This RFC depends on RFC 028 semantic targets and feeds inspection, bundles, plan diffs, governance, and export bridges.
Checklist