Chapter 1 of 8 · 4 checks · 2 min
Ownership and expectations
Checks need someone to act on them and a written standard to check against. Set these up before writing a single test.
Every production table has a named owning teamMust
Why it matters and how to check
When a check fails, someone has to decide whether to block the data, fix it or accept it. Google's Rules of Machine Learning include giving feature columns owners and documentation, and the same applies to every table people depend on. Record the owner where people already look: model YAML, the data catalog or the table description.
To verify, list every table in your production schemas and join it with your owner metadata. Any table without an owner is either unowned or unused; assign one or schedule it for removal.
Tables are tiered by impact so checks match what is at stakeShould
Why it matters and how to check
Not every table needs the same coverage. A table that feeds billing, a model or an executive dashboard deserves strict checks and paging alerts; a scratch table needs a primary key test and little else. Define two or three tiers, such as critical, important and best effort, and write down what each tier requires.
To verify, pick five critical tables and confirm each has the checks its tier requires and an alert route. Then pick five best-effort tables and confirm none of them pages anyone at night.
Freshness and quality expectations are written down per critical tableMust
Why it matters and how to check
A check needs a threshold, and a threshold needs a reason. Great Expectations' freshness guidance recommends documenting a clear service level agreement for how fresh each dataset needs to be, based on business needs, how often the source updates and pipeline lag. Do the same for completeness and correctness: which columns must never be null, which values are allowed, what row count is normal.
To verify, open the documentation for each critical table and find its freshness target, its required columns and its expected volume. If you have to ask someone, the expectation is not written down yet.
Checks live in version control and run on every changeMust
Why it matters and how to check
Checks defined by clicking in a UI drift and disappear. Keep them as code next to the models: dbt tests in YAML, Great Expectations suites, Soda contract files or SQL assertions. Review changes to checks in the same pull request as the model change, and run them in CI against a development schema.
To verify, change a model so it breaks a check, such as duplicating a key in a development branch, and confirm CI fails before the change can merge.