Data quality is the degree to which a dataset is accurate, complete, consistent, timely and valid enough to be trusted for the decision it supports. That last part matters more than the definition itself. A dataset can be technically flawless and still be the wrong input for the question being asked, which is why data quality is measured against use, not against an abstract ideal.
Quality failures are hard to detect because they do not interrupt execution. A pipeline that loads a wrong value completes successfully, so no alert fires and no log records an error. The data is simply incorrect, and nothing in the system is checking whether it is correct. That is why these failures surface through people rather than through monitoring, usually when someone questions a number in a report. The damage compounds beyond the single wrong figure, because once a team has found one incorrect number, it starts discounting the rest.
This guide covers what the dimensions of data quality actually mean in practice, how to test for them inside a pipeline, and how to tell the difference between checking data and observing it. The tooling matters less than the habit, but the tooling is where most teams get stuck, so we will get specific about that too.
The six dimensions of data quality
Data quality is not one property. It is a set of independent properties that fail independently, which is why a single "is the data good?" check never works. Breaking it into dimensions gives you something you can actually assert in code.
| Dimension | The question it answers | A concrete failure |
|---|---|---|
| Accuracy | Does the value match reality? | A customer's revenue recorded in the wrong currency |
| Completeness | Is anything missing? | 12% of orders arrive with no shipping address |
| Consistency | Do systems agree with each other? | The CRM and the warehouse report different customer counts |
| Timeliness | Is it fresh enough to act on? | Yesterday's inventory feeding a real-time reorder decision |
| Validity | Does it conform to the rules? | A date field holding 2026-13-45 |
| Uniqueness | Is each entity represented once? | The same supplier appearing four times with different IDs |
Accuracy is the hardest to test because it requires an external reference. The other five can be asserted mechanically, which is why a mature practice starts there and treats accuracy as a reconciliation problem against a source of record.
Notice that these dimensions carry different business weight depending on the use case. A marketing attribution model tolerates some incompleteness. A financial close does not. Deciding which dimensions matter for which dataset is an editorial judgment your team makes once and then encodes, and it is the step most often skipped.
How to test data quality inside the pipeline
The decisive shift is where the checks run. A check executed inside the pipeline can stop bad data before it reaches a consumer. A check executed after the data is already loaded can only tell you that a decision was made on a wrong number, which means the cost has already been paid.
In practice this means three layers. First, schema and type assertions at ingestion, so malformed records fail fast instead of propagating. Second, business rule assertions after transformation, where you encode what "valid" means for your domain. Third, reconciliation against a source of record for the numbers that carry the most weight.
The medallion architecture maps neatly onto this, with raw data landing untouched, cleaned data carrying the structural guarantees, and curated data carrying the business guarantees. The layering is not the point on its own. The point is that each layer has a different contract, so you know which failures belong where.
Where tooling fits
Open source validation frameworks let you express these assertions declaratively and run them as part of orchestration. Great Expectations is the most widely adopted of these, and its official documentation is a reasonable starting point for the assertion vocabulary. dbt tests cover a narrower surface but sit closer to the transformation logic, which some teams prefer.
The recurring question is whether a framework earns its complexity over custom validation scripts. The honest answer is situational. A handful of critical tables with stable rules does not need a framework. Dozens of tables, several teams, and a need for shared vocabulary and documented results does. BIX Tech works across both patterns, and the deciding factor is usually how many people need to read the results, not how many tables exist.
Data quality versus data observability
These two get used interchangeably and they are not the same thing. The distinction is worth holding onto because it changes what you build.
Data quality is assertive. You declare what should be true and the check fails when it is not. It catches the failures you anticipated.
Data observability is exploratory. It watches volume, freshness, schema and distribution over time and flags anomalies you did not think to assert. Data observability platforms exist precisely because the space of possible failures is larger than any test suite.
Teams that only assert are blind to the novel failure. Teams that only observe drown in alerts with no definition of correct. A working practice runs both, with assertions covering the known critical paths and continuous monitoring covering the rest. The two feed each other, since every anomaly that turns out to matter should become an assertion.
Where to start when nothing exists
Starting from zero, the instinct is to test everything. That produces a suite nobody maintains. A better sequence begins with the smallest useful surface and grows from evidence.
Pick the three datasets that feed decisions someone would escalate about. Write completeness and validity assertions on those, because they are cheap and catch the majority of real incidents. Add freshness checks next, since stale data causes more quiet damage than wrong data. Only then expand outward, and let each production incident tell you where the next assertion belongs.
The measure of success is not test coverage. It is how long a bad record survives before someone knows about it, and whether the people reading the dashboards have stopped asking whether the numbers are right.
Data quality work is unglamorous and it compounds. Every assertion you encode is a class of incident that stops recurring, and every incident that stops recurring buys back the trust that makes the whole analytics investment worth anything. The teams that get this right are rarely the ones with the most sophisticated stack. They are the ones who decided that "the pipeline ran" and "the data is correct" are two different claims, and built the second one on purpose.
If your team is deciding how to structure data quality checks across a growing pipeline, or reconsidering whether the current approach scales, our specialists can help you design an architecture that fits your context. Talk to our team and move your data maturity forward. ⬇️
What is data quality?
Data quality is how well a dataset serves the decision it supports, measured across accuracy, completeness, consistency, timeliness, validity and uniqueness. A dataset is not "high quality" in the abstract. It is high quality for a specific use, which is why the same table can be reliable for a marketing model and unusable for a financial close.
What is the difference between data quality and data observability?
Data quality is assertive and data observability is exploratory. Quality checks declare what should be true and fail when it is not, catching anticipated problems. Observability watches volume, freshness, schema and distribution over time to surface anomalies nobody thought to assert. Mature teams run both, because assertions cover known risks and observability covers the unknown ones.
How do you measure data quality?
Measure it per dimension, per dataset, as assertions that run inside the pipeline. Completeness and validity are the cheapest to implement and catch most real incidents. Accuracy needs reconciliation against a source of record. The useful operational metric is not test coverage but time to detection: how long a bad record survives before someone knows.
Where should a team start with data quality?
Start with the three datasets feeding decisions someone would escalate about, and write completeness and validity assertions on those. Add freshness next, since stale data causes more quiet damage than incorrect data. Expand from production incidents rather than trying to anticipate every failure, and let each one tell you where the next check belongs.
Do you need a framework like Great Expectations or are custom scripts enough?
It depends on how many people need to read the results. A few critical tables with stable rules run fine on custom scripts. Dozens of tables across several teams benefit from a shared assertion vocabulary and documented outcomes, which is what a framework provides. The number of tables matters less than the number of stakeholders.
