Use this issue to track InQL RFC 027, proposed in PR #60 at docs/rfcs/027_relational_evidence_program.md.
Area
- Specification (RFCs)
- Documentation
Summary
RFC 027 is the umbrella tracking RFC for InQL's relational evidence program. It defines the local, open semantic evidence contracts that make typed relational computation inspectable before execution and reviewable after execution: stable semantic targets, metadata attachments, Prism lineage, inspection artifacts, execution observations, adapter coverage, quality observations, governed attributes, plan bundles, plan diffs, evidence exchange bridges, interoperability semantic profiles, and Prism plan ingress.
Motivation
InQL already has typed carriers, Prism planning, Substrait lowering, registry-backed expressions, aggregate/window/generator semantics, and a session boundary. Without a coherent relational evidence program, lineage, governance, quality, observability, migration/modernization evidence, and change-impact work would grow as disconnected features and would risk reconstructing meaning from backend plans, session logs, external project artifacts, or display names instead of InQL semantics.
Proposal sketch
Add RFC 027 as the umbrella for the relational evidence program and use it to coordinate child RFCs 028-038, 040, and 041. The RFC should preserve the layer boundary where Prism-authored and Prism-rewritten plans are the source of local relational lineage, while session observations, backend observations, transformation-project artifacts, catalog metadata, and orchestration metadata attach evidence without redefining authored meaning.
Representative ecosystems include SQL systems such as Oracle, PostgreSQL, SQL Server, and MySQL; cloud and lakehouse targets such as Athena, Presto, Trino, Spark, Snowflake, BigQuery, Redshift, and Databricks; catalogs such as Glue Data Catalog and Hive Metastore; transformation projects such as dbt; and orchestrators such as Airflow, MWAA, Dagster, and Prefect.
Alternatives considered
The RFC draft rejects one giant governance RFC, one RFC per artifact file, Substrait metadata as the evidence store, and downstream integrations independently reconstructing evidence.
Impact / compatibility
This is additive. Existing plans may lack evidence artifacts until child RFCs are implemented. Serialized evidence artifacts must carry version metadata so consumers can distinguish unsupported evidence from empty evidence.
Implementation notes (optional)
Review PR #60 for the draft. Implementation should happen through the child RFCs rather than this umbrella issue alone.
Checklist
Use this issue to track InQL RFC 027, proposed in PR #60 at
docs/rfcs/027_relational_evidence_program.md.Area
Summary
RFC 027 is the umbrella tracking RFC for InQL's relational evidence program. It defines the local, open semantic evidence contracts that make typed relational computation inspectable before execution and reviewable after execution: stable semantic targets, metadata attachments, Prism lineage, inspection artifacts, execution observations, adapter coverage, quality observations, governed attributes, plan bundles, plan diffs, evidence exchange bridges, interoperability semantic profiles, and Prism plan ingress.
Motivation
InQL already has typed carriers, Prism planning, Substrait lowering, registry-backed expressions, aggregate/window/generator semantics, and a session boundary. Without a coherent relational evidence program, lineage, governance, quality, observability, migration/modernization evidence, and change-impact work would grow as disconnected features and would risk reconstructing meaning from backend plans, session logs, external project artifacts, or display names instead of InQL semantics.
Proposal sketch
Add RFC 027 as the umbrella for the relational evidence program and use it to coordinate child RFCs 028-038, 040, and 041. The RFC should preserve the layer boundary where Prism-authored and Prism-rewritten plans are the source of local relational lineage, while session observations, backend observations, transformation-project artifacts, catalog metadata, and orchestration metadata attach evidence without redefining authored meaning.
Representative ecosystems include SQL systems such as Oracle, PostgreSQL, SQL Server, and MySQL; cloud and lakehouse targets such as Athena, Presto, Trino, Spark, Snowflake, BigQuery, Redshift, and Databricks; catalogs such as Glue Data Catalog and Hive Metastore; transformation projects such as dbt; and orchestrators such as Airflow, MWAA, Dagster, and Prefect.
Alternatives considered
The RFC draft rejects one giant governance RFC, one RFC per artifact file, Substrait metadata as the evidence store, and downstream integrations independently reconstructing evidence.
Impact / compatibility
This is additive. Existing plans may lack evidence artifacts until child RFCs are implemented. Serialized evidence artifacts must carry version metadata so consumers can distinguish unsupported evidence from empty evidence.
Implementation notes (optional)
Review PR #60 for the draft. Implementation should happen through the child RFCs rather than this umbrella issue alone.
Checklist