Data engineering · AI
AI lineage needs a source of truth
Use AI to ask better questions about SQL. Use the AST and a typed resolver to ground the answers in repeatable evidence.
When an AI assistant explains a SQL procedure, the explanation is most useful when you can follow each claim back to the code. A lineage graph provides that evidence: which columns feed an output, which transformations connect them, and which statements created the edges.
Let the structure ground the answer
SQL Lineage parses SQL with a dialect-aware grammar, builds a typed, dialect-neutral model, and resolves lineage from that model. The abstract syntax tree (AST) is the structural source of truth for the SQL supplied to the analysis. The resolver adds scope, catalog information, and dialect semantics to turn that structure into dependencies.
This distinction matters. A parse tree alone cannot tell you every column hidden behind a star or supply the body of a routine that was never provided. Accurate lineage needs both syntax and context.
flowchart LR SQL[SQL and catalog] --> AST[Typed AST] AST --> Graph[Lineage and diagnostics] Graph --> AI[AI explanation with evidence]
Repeat the analysis, inspect the difference
Hold the SQL, dialect, catalog, environment, options, and engine version constant when comparing lineage results. These are the inputs to the analysis; a rewritten prompt should not decide which source column feeds a result. Compare the semantic graph and diagnostics, rather than transient analysis IDs or timestamps.
Engine upgrades can change results as support improves or bugs are fixed. Pin a release, keep representative SQL fixtures, and review graph changes before upgrading. The grammar corpus and lineage regressions make these changes testable; they do not prove correctness for every possible script.
Give AI a useful role
A practical integration can call the lineage and provenance APIs, then give their structured output to an assistant. Ask it to explain a dependency, propose a migration, or summarize the affected reports. Require references to the returned statements and origins, and show diagnostics alongside the explanation.
After AI proposes an edit, analyze the revised SQL again and compare dependencies. Validate behavior in your database and review the business meaning. Structural analysis supports that review; it does not establish that a change is safe in every runtime setting.
Make uncertainty visible
Missing catalogs, ambiguous columns, unsupported syntax, and dynamic SQL that depends on query results can limit completeness. A repeatable answer can still be incomplete. Treat diagnostics as part of the result and avoid turning a partial graph into a confident claim.
SQL Lineage provides the analysis API for this workflow. Connecting it to your chosen AI assistant is an integration you build; the product does not send your SQL to an AI provider automatically.
Explore the AI + lineage approach → · Read the integration guide →