Foundational continuously scans your code and data pipelines - across dbt, Airflow, Snowflake, BigQuery, Redshift, Databricks, Spark, Looker, Power BI, Tableau and 30+ other platforms - and builds a unified, column-level lineage graph of how data flows between tables, columns, dashboards and jobs. On every pull request, and on an ongoing basis, we analyze that graph to catch problems before they reach production.
This document is the full catalog of what Foundational detects, grouped into meaningful categories, each with a description and severity.
How detection works
On a pull request (pre-merge): We compare the lineage graph as it exists today against how it would look after your change, and flag anything the change would break or degrade. This is where breaking changes are caught.
Continuously (post-merge / scheduled): Data observability monitors run against your warehouses to catch freshness, volume and data-quality problems as they happen.
At scan time: Parsing and compilation checks confirm we can fully understand each project, so lineage stays complete and trustworthy.
Severity levels
Severity | Meaning |
Critical | A project could not be compiled or understood; lineage for the affected asset may be incomplete until resolved. |
Error | A change or condition that will break a downstream consumer or produce incorrect results. |
Warning | A likely problem or risky change that should be reviewed, but may be intentional. |
Informational | A suggestion or best-practice gap; no immediate impact. |
Every detection is configurable per organization - individual checks can be tuned, scoped to specific platforms, or disabled to match your team's workflow.
What is a breaking change?
A breaking change is a code change that removes or alters a table or column that other assets still depend on - leaving a downstream query, model, dashboard or job pointing at data that will no longer exist, or no longer match.
Foundational detects breaking changes by diffing the lineage graph. Because that graph is unified across platforms and resolved down to the individual column, a change is caught no matter how many transformations or platform hops separate it from the asset it affects - e.g. a column dropped in a dbt model is flagged even when the thing that depends on it is a downstream Snowflake view, a Looker explore, a Power BI dashboard, or an Airflow job.
Breaking Schema Changes
Forward-looking checks that run on every pull request and pinpoint exactly which downstream assets a change would break - across every connected platform, down to the individual column.
Detection | Severity | What it means |
Removed table still in use | Error | A change deletes a table that downstream models, queries, dashboards, or jobs still read from. Foundational names every consumer that would break. |
Renamed table still in use | Error | A change renames a table, but downstream assets still reference it by its old name and will break. |
Removed column still in use | Error | A change deletes a column that is still consumed downstream - caught at the individual-column level, even when it is read many steps away from where it was removed. |
Renamed column still in use | Error | A change renames a column, but downstream assets still read it by its old name and will break. |
Column Type Change | Warning | A column's data type changes in a way that can break or silently corrupt the downstream consumers that read it (for example, a numeric column becoming a string). |
Breaking change reaching BI & operational tools | Error | A change in one system breaks an asset in a different one - a Power BI, Looker, or Tableau dashboard; a reverse-ETL sync; a Spark or Airflow job. These cross-platform breaks are invisible to single-tool checks. |
Reference to a non-existent table | Error | A model, query, or dashboard references a table that does not exist in any connected source - a typo, an object that was dropped, or a source that was never created. |
Reference to a non-existent column | Error | An asset reads a column that does not exist on its source table, so the query will fail or silently return no data. |
SQL Correctness & Semantics
Foundational statically analyzes SQL across every dialect in your stack - Snowflake, BigQuery, Redshift, Databricks, Athena, Postgres, and more - and surfaces correctness and semantic problems before the SQL ever runs.
Detection | Severity | What it means |
SQL Syntax Error | Error | SQL that is grammatically malformed and will fail to parse or compile. |
SQL Type / Cast Error | Error | SQL that parses correctly but contains an invalid type conversion - casting a value to a type it cannot become, or an invalid timestamp or temporal expression - which fails at runtime or silently corrupts results. |
Unresolved Reference | Warning | A query references a table, column, or schema that cannot be resolved in its context, indicating a likely broken or out-of-date reference. |
SQL Column Ambiguity | Error | A column reference is ambiguous across joined tables, so the engine may resolve it to the wrong source and return unexpected values. |
Union Size Mismatch | Warning | The branches of a UNION return different numbers of columns, which fails or misaligns the combined result. |
Union Names Mismatch | Warning | The branches of a UNION carry mismatched column names, risking mislabeled output downstream. |
Unhandled Enum (non-exhaustive CASE) | Warning | A CASE expression does not cover all known values of its input, leaving unhandled values to fall through unexpectedly. |
dbt Enum Mismatch | Warning | A column's data contains values outside the set declared as accepted for it. |
Duplicate Definition | Warning | The same table or entity is defined in more than one place, creating ambiguity about the source of truth. |
Metadata & Governance
Detection | Severity | What it means |
Missing Description | Warning | A table or column has no description, reducing discoverability and governance coverage. |
Missing Enum Test | Informational | A column expected to be validated against an enumerated set has no such test or validation. |
Data Observability & Quality
Continuous monitors that watch your data after it lands, catching freshness and anomaly problems automatically.
Detection | Severity | What it means |
Freshness | Warning | A table has not been updated within its expected time window. |
Row Count Freshness | Warning | A table's row count has not changed when new data was expected. |
Volume Anomaly | Warning | An unusual spike, drop, or zero in the volume of data written. |
Row Count Threshold Violation | Warning | A table's row count fell outside its expected range. |
Count Threshold Violation | Warning | A monitored value count fell outside its configured threshold. |
Value Count Anomaly | Warning | The distribution of values in a column deviated from what is expected. |
Value Rate Anomaly | Warning | The rate of unexpected or invalid values in a column is too high. |
Monitor Failure | Warning | A monitoring query failed to execute. |
Monitored Entity Missing | Error | A table that is under active monitoring no longer exists. |
This catalog reflects the detections available on the Foundational platform. The exact set enabled for your organization, and their thresholds, can be tailored to your needs - reach out to your Foundational contact to review or adjust your configuration.