Validation Reports¶
Use these reports to evaluate GSP against SQL that is closer to production than a small feature example. Each report records the input project, expected relationships, detected relationships, discrepancies, and known limitations so you can judge whether the tested patterns resemble your workload.
Data Lineage Validation¶
The data-lineage validation reports compare output from the
GSP DataFlowAnalyzer with an independent analysis of the same SQL files. Each
report documents:
- What lineage was correctly detected
- What lineage was missed (with root cause analysis)
- Crashes or errors encountered
- The reason for a discrepancy when it can be identified
Reports are organized by database vendor, with multiple test suites per vendor covering different SQL patterns and complexity levels.
Latest Results¶
| Vendor | Test Suite | Accuracy | Issues | Report |
|---|---|---|---|---|
| Oracle | DB Sample Schemas | 96% | 1 | Report |
| SQL Server | SQL Data Warehouse Project | 100% | 0 | Report |
| Snowflake | Mattermost Data Warehouse (dbt) | 0% | 46 | Report |
| DuckDB | SOMA B2B SaaS (dbt) | 0% | 33 | Report |
How to use these results¶
- Open the report for the database and project closest to your input.
- Review the SQL patterns tested, not only the summary percentage.
- Inspect missed or incorrect relationships and their documented causes.
- Reproduce the important cases with your metadata and parser version before using lineage for a production decision.
The reports are evidence for the listed corpus and version, not a guarantee that every repository with the same database label will produce the same result. Dynamic SQL, incomplete metadata, generated objects, naming rules, and project conventions can materially change lineage resolution.
Continue with the column-level data-lineage guide to understand the integration workflow, or check SQL syntax support for parser coverage by dialect.