Concepts
& vocabulary.

Tests are explicit statements of what should be true ("order_id is never null", "revenue is positive", "customer_id exists in dim_customer"). Deterministic, debuggable, reviewable in pull requests. Complement rather than replacement for ML anomaly detection — assertions encode known rules, anomaly detection surfaces unknown unknowns.

Not the same as ▸ ML Anomaly Detection

Traces data flow at the individual column granularity rather than just between tables. Critical for impact analysis when a column changes, for PII tracking, and for regulatory compliance in financial or healthcare contexts. Column-level lineage is computationally expensive and not all tools that claim "lineage" actually provide it — many stop at table level.

Not the same as ▸ Table-Level Lineage · Transformation Lineage

Runs as part of the dbt execution context — as a package, post-hook, or artifact consumer — rather than monitoring the warehouse from the outside. Tests are defined in the same codebase as models, run on the same schedule, and fail the same CI pipeline. The alternative is warehouse-side monitoring (Monte Carlo-style) which catches issues dbt misses but reacts rather than prevents.

Not the same as ▸ Warehouse-Native Monitoring

Alerts when a monitored table's schema changes — columns added, removed, or retyped. Catches silent breaking changes from upstream systems. A floor capability, not a differentiator — treat any tool without it as incomplete.

Not the same as ▸ Data Contracts

A managed vocabulary of business terms ("Active Customer", "Recognized Revenue") with definitions, owners, and — critically — links to the physical assets that implement them. Without the linking layer a glossary is just a wiki. With it, you can answer "which dashboards use our official definition of Active Customer?" — the question governance teams actually care about.

Halts downstream execution when a test fails — preventing bad data from propagating into marts, ML features, or BI dashboards. Requires tight integration with the orchestrator (Airflow, Dagster, dbt Cloud). Distinct from alerting-only tools which notify after damage is done.

Explicit, versioned agreements between data producers and consumers specifying schema, semantics, SLAs, and breaking-change policy. Enforced in CI for producers and at consumption time for consumers. Distinct from schema validation alone — a contract captures intent, not just structure. Implementations vary wildly; many tools claiming "data contracts" offer only schema checks.

Not the same as ▸ Schema Change Detection

Uses machine learning models trained on historical data to detect values, volumes, or distributions outside expected bounds — without requiring the user to write explicit assertions. Reduces the "I didn't know to test for that" class of incident. Trade-off: requires a training window (typically two to four weeks), can produce false positives on seasonal data, and doesn't replace assertions for business-rule validation.

Not the same as ▸ Assertion-Based Testing

Emits and consumes OpenLineage events as a first-class citizen rather than via a plugin or adapter. Signals commitment to interoperability with other metadata tooling — Marquez, OpenMetadata, Astronomer, and others can consume the same event stream. Increasingly the differentiator between "open" and "proprietary metadata model" observability platforms.

Automatically identifies columns likely to contain personally identifiable information — email addresses, phone numbers, national IDs — through regex, name heuristics, or ML. Required for meaningful compliance workflows at scale. Quality varies: naive implementations produce heavy false-positive rates. Worth asking vendors about their accuracy benchmarks.

Compares the output of a model change against production before the pull request is merged — showing row-level and aggregate differences. Shifts data quality left into the development workflow. Datafold is the category-defining tool here; dbt's own cloud offering has added similar capabilities. Requires production-scale compute on a development branch, which has cost implications.

Traces data flow between tables but not within them. Adequate for high-level impact analysis and data discovery. Less expensive to compute and present than column-level lineage. Most tools that advertise "lineage" without qualification mean table-level.

Not the same as ▸ Column-Level Lineage

Monitors tables directly in the warehouse via query log parsing or scheduled metric queries — independent of the pipeline that produced the data. Catches issues regardless of which tool wrote the data, including ingestion-layer problems dbt can't see. Trade-off against dbt-native testing: reactive rather than preventive, and adds warehouse cost.

Not the same as ▸ dbt-Native Testing

Given a downstream asset — typically a dashboard or a metric — traces backward to every upstream table, column, and pipeline it depends on. The inverse of forward impact analysis. Valuable for debugging ("this dashboard is wrong, what could have caused it?") and for establishing the blast radius of historical incidents.

Exposes the specific SQL or code that transforms upstream columns into downstream columns — not just "A depends on B" but "here is the CASE statement that produces this value". Useful for debugging and for auditors. Only a handful of tools (Manta, Datafold, some DataHub configurations) provide this depth.

Not the same as ▸ Column-Level Lineage