Checklist · Data and ML
Data Quality Checklist
Opens with creditsA checklist for keeping warehouse and lakehouse tables trustworthy. It covers ownership and expectations, freshness, volume, schema, nulls, uniqueness and valid values, referential and reconciliation checks, anomaly monitoring and handling data incidents, with a severity and a way to verify each check.
Written by Tauseef Fayyaz8 chapters, 33 checksAbout 17 minReviewed 13 October 2026What you will learn
8 chapters · about 17 min
1Ownership and expectationsChecks need someone to act on them and a written standard to check against. Set these up before writing a single test.4 checks · 2 min
2FreshnessStale data is the most common silent failure: every job succeeds while the numbers stop moving. These checks catch it.4 checks · 2 min
- VolumeA table can be fresh and still be missing half its rows. Volume checks catch partial loads, duplicated loads and filters that broke.4 checks · 2 minOpens with credits
- SchemaUpstream teams rename columns, change types and add fields without telling anyone. These checks stop schema changes at the door.4 checks · 2 minOpens with credits
- Nulls, uniqueness and valid valuesThe cheapest checks catch the most common bugs: duplicate keys from bad joins, missing required values and categories nobody expected.4 checks · 2 minOpens with credits
- Referential and consistency checksTables that are fine alone can still disagree with each other. These checks cover relationships between tables and agreement between related numbers.4 checks · 2 minOpens with credits
- Anomaly monitoringFixed rules catch the failures you predicted. Monitoring distributions over time catches the ones you did not.4 checks · 2 minOpens with credits
- Data incident handlingWhen bad data reaches people, the response matters as much as the fix. These checks borrow from Google's SRE incident practices and apply them to data.5 checks · 3 minOpens with credits
About this checklist
Bad data rarely announces itself. The pipeline finishes, the dashboard loads, and the number is wrong: a source stopped sending rows on Tuesday, a column changed type, a join started duplicating orders. Google's Rules of Machine Learning call these silent failures, and they are the reason a data quality checklist exists. Every check here is designed to turn a quiet problem into a loud one before a person or a model relies on the data.
The checks follow the dimensions most data quality tools share. Great Expectations groups its use cases into freshness, volume, schema, missingness, uniqueness, distribution and integrity, and Google Cloud's data quality scans tie every rule to a dimension such as freshness, volume, completeness, validity, consistency, accuracy or uniqueness. Whatever tool you use, whether dbt tests, Great Expectations, Soda contracts or plain SQL, the same questions need answers.
The checklist starts with ownership, because a failing check that nobody owns is just noise. It then moves through the checks themselves, from the cheap ones every table should have to anomaly monitoring for the tables that matter most, and ends with how to handle a data incident when a check fires.
Each check has a severity (must, should or nice) and a concrete way to verify it, such as a query to run, a config to read or a test to break on purpose. For how pipelines should load data so these checks stay meaningful, see the data pipeline best practices guide in this library.
Common questions
What are the main dimensions of data quality?
Most tools share a similar list. Great Expectations groups checks into freshness, volume, schema, missingness, uniqueness, distribution and integrity. Google Cloud's data quality scans use freshness, volume, completeness, validity, consistency, accuracy and uniqueness. The names differ, but the questions are the same: is the data on time, complete, well formed, unique and correct?
Which data quality checks should every table have?
At minimum, unique and not_null tests on the primary key, a freshness check against a written target, and a check that loads are not empty. Critical tables then add null thresholds on required columns, accepted values, relationship tests on foreign keys and volume compared with history.
What is the difference between data tests and data observability?
Data tests check rules you wrote in advance, such as unique keys or allowed values, and pass or fail on each run. Observability or anomaly monitoring tracks statistics like row counts and null rates over time and flags unusual changes you did not predict. Most teams need both: tests for known rules, monitoring for the rest.
Should a failed data quality check stop the pipeline?
It depends on severity. Broken keys, schema changes and empty loads should stop downstream models, because the output would be wrong. Small distribution shifts or a few unexpected values should warn the owner instead. dbt supports this with error and warn severities and thresholds.
What should I do when bad data reaches a dashboard?
Treat it as an incident: stop the bad data spreading by pausing consumers or flagging the dashboard, tell the people who use it what is affected and what to avoid, fix the cause, backfill the affected period and recheck it, then add a check that would have caught the problem sooner.
Sources (8)
Checked against these, last on 13 October 2026.
- Add data tests to your DAG, dbt docsdocs.getdbt.com/docs/build/data-tests
- freshness, dbt docsdocs.getdbt.com/reference/resource-properties/freshness
- Data quality use cases, Great Expectations docsdocs.greatexpectations.io/docs/reference/learn/data_quality_use_cases/dq_use_cases_lp
- Validate data freshness with GX, Great Expectations docsdocs.greatexpectations.io/docs/reference/learn/data_quality_use_cases/freshness
- Contract Language Reference, Soda docsdocs.soda.io/soda-v4/reference/contract-language-reference
- Auto data quality overview, Google Clouddocs.cloud.google.com/dataplex/docs/auto-data-quality-overview
- Managing Incidents, Google SRE booksre.google/sre-book/managing-incidents/
- Rules of Machine Learning: Best Practices for ML Engineering, Google for Developersdevelopers.google.com/machine-learning/guides/rules-of-ml
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Data Pipeline Best PracticesHow to build data pipelines you can re-run, test and trust: idempotent tasks, orchestrator hygiene, layered transformations, data tests, freshness, ownership and monitoring.
- Data Analysis Best PracticesAn analyst's workflow in SQL, pandas and Polars: framing the question, reading data correctly, joins and grain, aggregation pitfalls, reproducible notebooks, checking results and sharing findings.
- Data Modeling Best PracticesDimensional data modeling for analytics: declaring the grain, fact and dimension tables, slowly changing dimensions, dbt marts, naming, tests, contracts and a semantic layer.
Checklists
See all- Analytics Dashboard ChecklistAn analytics dashboard checklist for launch day: purpose and audience, metric definitions, data freshness, correctness, performance, access, accessibility, ownership and adoption.
- ML Model Deployment ChecklistAn ML model deployment checklist: baselines, training and serving consistency, validation, model registry, canary rollout, rollback, drift monitoring and ownership, with how to verify each.
- RAG Production ChecklistA RAG production checklist: chunking, embeddings, hybrid search, reranking, per-user permissions, citations, evals, re-indexing and cost, with how to verify each check.
Project structures
See all- dbt project project structureA dbt project that turns raw tables into tested, documented models, using the staging, intermediate and marts layers from dbt's own structure guide. It runs on DuckDB on your laptop, so you can learn analytics engineering for free, and grows into a governed project with checks, contracts, slim CI and a hosted docs site that moves to BigQuery or Snowflake unchanged.
- Apache Airflow project structureFor data engineers scheduling real pipelines with Airflow 3. It starts from
astro dev init(dags, include, plugins, tests and a Runtime Dockerfile that runs Airflow locally in Docker) and grows into dags grouped by business area, logic in a tested include package, asset-driven scheduling, data quality checks, alerts, CI that parses and tests every dag, and dag-only deploys. A self-hosted docker compose and Helm route is shown alongside. - MLOps pipeline project structureFor engineers who can train a model and now need the training to be a pipeline anyone can rerun, review and release. A uv workspace holds the pipeline package (prepare, validate, featurize, train, evaluate, register steps run by DVC), a small shared feature package, and a separate FastAPI prediction service that loads models from the MLflow registry by alias. It grows into CI that reproduces the pipeline on pull requests, scheduled retraining, approved promotion and monitoring.
Career questions
See all- What is the difference between a data analyst, a data scientist and a machine learning engineer?Analysts answer business questions with SQL, spreadsheets, dashboards and reports. Data scientists add statistics, experiments and predictive models. ML engineers build and run models inside production software. Titles vary by company, so read the work in the job advert, and pick by the kind of problem you enjoy, not the title that sounds most senior.
- Should I learn Python or R for data science?For most people aiming at industry jobs, learn Python first: it covers analysis, machine learning and production code, and most data job adverts ask for it. Choose R first if you are heading into statistics, academic research, public health or survey work, where it is strong. Either way, SQL comes too, and the concepts transfer.
- How do I move into AI engineering, data science or DevOps?Pick the field by the work you want to do every day, not by the hype. Use what you already know as a bridge: developers usually reach AI engineering or DevOps fastest, analysts reach data science fastest, and a portfolio of one or two serious projects matters more than certificates.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com