authoring-data-quality-checks

Use the data-quality-check-create-on-table or create-on-view MCP tool with the table or saved query ID, specifying a check type like not_null, unique, or freshness. Then run it once with the corresponding run tool and poll the results to verify it works.

Supported check types are not_null, unique, relationships, accepted_values, freshness, row_count bounds, and custom_sql for arbitrary HogQL assertions. Each check passes when it finds zero failing rows, matching dbt test semantics.

Query system.information_schema.data_quality_health for the subject's verdict. A failing status means an error-severity check found bad data, healthy means checks passed, and unknown means no checks exist, which is not evidence of health.

An errored result means the check query could not run at all, usually due to a column name typo or a subject that no longer exists. It is never a data problem, so fix the check configuration rather than investigating the data.

No, the assertion (type, column, config) and subject are immutable after creation. Create a corrected check and delete the old one instead; updates are only allowed for metadata, severity, and ownership.

Checks run when their subject's data changes: materialized view checks run during refresh, source table checks run after each sync, and view checks run when their DAG runs. Views outside any DAG only run on demand.