Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
Quality control in data management: the 4 checks that run where data moves, the thresholds that trip them, who gets paged, and what happens to failed rows.
Updated on
Quality control in data management is the set of checks that run at the moment data moves, deciding whether a specific batch is allowed to reach the people who use it. It is an operating discipline rather than a policy: a check, a pass value, a named person and a decision about what happens to the rows that failed. Most articles on the subject stop at the definition and the list of quality dimensions. This one starts where the check goes red.
The four practices below are ordered the way you would build them. Write the acceptance specification first, because a check without a written standard is a guess. Put the inspection at the release point, because a check that runs after a consumer has already read the table is a report rather than a control. Decide the disposition in advance, because the decision made during an incident is the wrong one. Record the measured value on every run, because a threshold you did not derive from history is a number somebody made up.
Quality control in data management is the systematic inspection of a dataset against a written standard, carried out before that dataset is released for use, to confirm that it is accurate, complete, consistent and timely enough for the decisions it feeds. In practice it is four activities running together: profiling to learn what the data contains, cleansing to correct what is wrong, validation to reject what does not conform, and monitoring to notice when any of it changes.
The word control is doing real work in that sentence. A control is something that stops an outcome, not something that observes it. If a failing check produces a dashboard tile and nothing else, you have measurement, not control. The test of whether a team has quality control is simple: name a batch of data that was stopped from reaching a consumer in the last quarter, and name the person who stopped it. If nobody can, the checks are reporting.
That distinction also decides what belongs on this page and what does not. Deciding which dimensions to measure and how to score a dataset against them is the wider subject of data quality management, and the scoring model and the six dimensions are covered there. What follows here is narrower: the checks themselves, the point in the pipeline where they run, the person who answers when one fails, and what happens to the data that failed.
These four terms are used interchangeably in most vendor content and they are not the same job. They differ on what question they ask, when they run and who is answerable. Getting them confused is why so many teams have monitoring dashboards and still ship bad data: they built observability and called it control.
| Discipline | The question it asks | When it runs | What it produces |
|---|---|---|---|
| Quality control | Does this specific batch meet the written standard? | At the point data moves, before the batch is released to a consumer | A pass or fail verdict on one batch, and a disposition for the rows that failed |
| Quality assurance | Is the process capable of producing conforming data at all? | At design and review time, before the pipeline is built or changed | Changed pipelines, schemas, contracts and source system rules |
| Data quality management | Is the organization's data fit for purpose over time? | Continuously, on a program cadence with owners and reviews | Standards, ownership, scorecards, a remediation roadmap |
| Data observability | Has this pipeline behaved the way it usually behaves? | Continuously, on live tables, without a written standard to compare against | Anomaly alerts on freshness, volume, schema and distribution |
The practical difference between the first and the last row is the written standard. Observability tells you a table changed. Quality control tells you the table is outside the range you agreed to publish inside, which is a different and more useful sentence, because it names the commitment that was broken. The boundary between the two is worth reading in full if you are choosing tooling, and it is set out in data quality and data observability.
Quality control is also not the whole program. Ownership models, the severity ladder, response times, the incident runbook and the review cadence are program level questions and they are answered in data quality management best practices. This page assumes those exist and describes the checks that run inside them.
Each of the four practices below commits to the same five fields: the check that runs, where in the pipeline it runs, the value that counts as a pass, who answers when it fails, and what happens to the data that failed. If you only read one thing on this page, read this table and fill the five columns in for your own most important dataset.
| Practice | The check that runs | Where it runs | Who is paged | What happens to the failed data |
|---|---|---|---|---|
| 1. Write an acceptance specification | None yet. This practice produces the standard every later check compares against. | In the repository, next to the model that builds the dataset | Nobody. A missing specification is caught at review, not at runtime. | Nothing. Without a specification there is no definition of failed. |
| 2. Inspect the batch at the release point | Row count, freshness, schema, null rate, uniqueness, referential coverage, accepted values | Between load and publish, against the staged batch, before the consumer table is swapped | The dataset owner named in the specification | It stops at staging. The consumer table keeps yesterday's good batch. |
| 3. Give every failure a disposition | None new. This practice decides the consequence of the checks in practice 2. | Written into the check definition, applied automatically when the check fails | The owner, who can override the default disposition and is accountable for doing so | Blocked, quarantined into an audit table, or released with a written notice |
| 4. Record the measured value on every run | The same checks as practice 2, but storing the number rather than the verdict | Wherever check results are written, retained for at least 90 days | Nobody in the moment. The series is read at the review, not at 3am. | Nothing new. This practice makes the next threshold defensible. |
A check without a written standard is somebody's opinion in code. The acceptance specification is the artifact that turns it into a control: one short document per dataset saying what conforming looks like, who agreed to it, and what happens when it does not hold. It lives in the repository next to the model that builds the dataset, so a change to the standard goes through the same review as a change to the code.
Six fields, and no check ships until all six are filled in.
| Field | What goes in it | Worked example |
|---|---|---|
| Dataset and grain | The table and what one row represents | analytics.fct_orders, one row per order line |
| Consumer commitment | The decision or report that breaks if this dataset is wrong | The daily revenue report the finance team sends to the board at 09:00 |
| Measurement | The exact thing counted, in plain language a non engineer can check | Share of rows where order_value is null |
| Pass value | The number, derived from observed history rather than chosen | At or below 0.5 percent, being the worst value in the last 90 days plus headroom |
| Owner on failure | The named person, not a team alias, who answers | The analytics engineer who owns fct_orders, with the data platform rota as backup |
| Disposition | What happens to the batch when the check fails | Block the release. Finance would rather have yesterday's number than a wrong one. |
The hard part is deciding which columns to specify. A wide table has hundreds and specifying all of them produces a wall of alerts nobody reads. The decision rule that works: specify a column if a wrong value in it changes a number somebody acts on. A column somebody joins on, filters on or sums qualifies. A free text notes field nobody aggregates does not. On a typical fact table that leaves eight to fifteen columns, not two hundred.
Do not choose the pass value before you know the current one. Run a profile of the table first and read the actual null rates, distinct counts and value ranges, then set the pass value from what the data does today plus headroom. The statistics a profiler computes, and what a bad value looks like for each of them, are covered in data profiling. A threshold picked in a meeting before anyone looked at the table is the single most common reason a check fires every morning and gets muted in week two.
The release point is the moment a new batch becomes visible to the people who read the table. Quality control belongs exactly there, and the pattern is three steps: write the incoming batch into a staging table, audit that staged batch against the acceptance specification, and publish it into the consumer table only if the audit passes. When the audit fails, the consumer table is untouched and still holds the last batch that passed. The consumer sees stale data instead of wrong data, which is almost always the better of the two failures because stale data announces itself and wrong data does not.
Seven checks belong at that release point. They are cheap, they run against the staged batch rather than the full table, and between them they catch the great majority of what actually goes wrong in production pipelines.
| Check | What it measures on the staged batch | A pass value you can start from | What it catches |
|---|---|---|---|
| Row count against history | Rows in this batch compared with the same weekday over the last eight weeks | Within 30 percent of the trailing median for that weekday | A partial load, a silently dropped source file, a duplicated run |
| Freshness | The maximum event timestamp in the batch against the clock | No older than the promised delivery time plus one hour | An upstream job that failed quietly and left yesterday's data in place |
| Schema conformance | Column names, types and order against the specification | Exact match, no exceptions | A renamed or retyped source column, the most common cause of silent breakage |
| Null rate on specified columns | Share of nulls in each column named in the specification | At or below the worst value observed in the last 90 days, plus headroom | A source system change that stopped populating a field |
| Uniqueness of the business key | Distinct count of the key against row count | Equal, with zero tolerance on a key you join on | A duplicated load, which inflates every sum built on the table |
| Referential coverage | Share of foreign keys in the batch that exist in the parent table | At or above 99.9 percent, with the shortfall listed rather than counted | Orphan rows that quietly disappear from any inner join downstream |
| Accepted values | Distinct values in coded columns against the agreed list | Zero values outside the list | A new status code the downstream logic has never seen and silently ignores |
Give every check two levels rather than one, because not every failure should stop a release. The dbt convention is a useful concrete model: a test carries a severity of either error or warn, with error as the default, and two conditional expressions, error_if and warn_if, both defaulting to a failure count that is not equal to zero. Setting error_if to a larger number and leaving warn_if at the default gives you a check that warns on the first bad row and only stops the release once the count crosses a threshold you chose. The exact behavior is set out in the dbt test severity reference, read on 6 September 2026. The same two level shape works in any framework.
These seven are batch level checks. The record level rules that reject an individual row at ingestion, the format and range and cross field rules, are a different layer that runs earlier and belongs to data validation. Run both. Record level validation stops a bad row entering the batch, and release point inspection stops a bad batch reaching a consumer, and neither substitutes for the other.
The disposition is what happens to the data that failed. There are only three sensible answers, and the decision belongs in the check definition, written down in advance, because the same person will make a different call at 09:00 on a Tuesday than at 03:00 on a Sunday.
| Disposition | When you choose it | What the consumer sees | What has to exist for it to work |
|---|---|---|---|
| Block the release | When acting on a wrong number cannot be undone: a payment file, a regulatory return, a balance shown to a customer | The previous good batch, plus a notice that today's load is held | A consumer table that is separate from staging, and somebody empowered to hold a release |
| Quarantine and release the rest | When the batch separates cleanly by row and the good rows are useful without the bad ones | A partial batch, with the withheld row count published alongside it | A quarantine table, a replay route back once the rows are fixed, and a rule for how long a row may sit there |
| Release with a written notice | When the defect is bounded, measured and understood, and withholding the batch would cost more than the defect | The full batch plus a dated note saying exactly which column is affected and by how much | A place the notice is actually read, such as the table description in the catalog rather than a chat message |
Quarantine needs somewhere for the rows to go, and the mechanics are worth copying from a tool that already solved it. In dbt, the store_failures configuration saves the records that failed a test into a table named after the test, in a schema that defaults to the profile schema with the suffix _dbt_test__audit, and each run replaces the previous failures for that test rather than appending to them. The details are in the dbt store_failures reference, read on 6 September 2026. That last detail matters more than it looks: if you want a history of what failed, you have to write it somewhere the next run does not overwrite.
Three rules make dispositions hold up under pressure. Default to blocking on anything a consumer cannot withdraw once they have acted on it. Never quarantine a row without a route back, because a quarantine table nobody replays is a delete with extra steps. And put a maximum age on quarantined rows, so that a row sitting there for six weeks becomes a decision somebody has to make rather than a silent loss.
The person who makes the call is the owner named in the acceptance specification, working inside the severity levels and response times the wider program sets. Those are defined once for the whole organization rather than per check, and how to set them is covered in data quality management best practices.
Most quality control implementations store a verdict. The check ran, the check passed, green tile. That throws away the only thing that would have warned you. Store the number the check measured, every run, with a timestamp, and keep at least 90 days of it.
A null rate that reads 0.4 percent every morning for a month and 1.9 percent today has not breached a 5 percent threshold. Nothing fires. But it has moved by a factor of nearly five, and something upstream changed to make it move. With the series stored, that is a visible step change on a chart at the weekly review. With only the verdict stored, it is invisible until the day it crosses 5 percent, which may be a month later and three releases downstream of whatever caused it.
The series buys three concrete things. It lets you set the next threshold from the observed distribution rather than from a round number somebody liked. It gives an auditor a defensible answer to the question of how you knew the data was within tolerance on a particular date, which a green tile does not. And it tells you which checks to retire: a check whose measured value has not moved outside a narrow band in six months is watching something that does not vary, and it is costing review attention that a check with real variance needs.
Set the first threshold at the worst value observed over 90 days plus headroom, then tighten it once a quarter as the series gives you confidence. Starting loose and tightening produces a check people trust. Starting tight and loosening produces a check people mute in week two, and a muted check is worse than no check because it looks like coverage on a report.
The four practices above work with nothing more sophisticated than SQL and a scheduler. Four technologies make them cheaper to run at scale, and it is worth being precise about what each one actually removes from the job.
Lineage is the one worth spending time on, because it is the difference between knowing a table is broken and knowing what breaks with it. Decube's column level data lineage traces the flow from the source column through every transformation to the dashboard that reads it, so the impact question is answered from the graph rather than from memory. Getting the coverage question right in the first place, so that new assets are discovered rather than missed, is the subject of smart data discovery in data governance.
None of the four decides anything for you. A model can propose a threshold and an assistant can draft a check, but the acceptance specification is a commitment between a producer and a consumer, and the disposition is a judgment about what a wrong number would cost. Those stay with people. The old rule about what a system does with bad input has not stopped being true because the system got clever: a model trained on data that never passed an inspection will produce confident output that nobody should act on.
Clinical data management runs the same four practices under a regulator, and the differences are worth naming because they show what quality control looks like when the consequences are not negotiable.
The acceptance specification here is a regulated document rather than an internal one: the data management plan and the edit check specification, agreed before the first patient is enrolled and changed only through a controlled amendment. The release point is not a nightly batch, it is database lock, the single moment after which the dataset is frozen for analysis. The disposition options are narrower: releasing with a written notice is generally not available, so a discrepancy becomes a query raised against the site, answered, and resolved before lock. And the measurement series is not optional, because the audit trail has to show every value that changed, who changed it and why.
The transferable lesson for a commercial data team is the edit check at the point of entry. Clinical systems refuse an out of range value at the screen where a coordinator types it, rather than catching it in a warehouse three days later, because the person who can resolve the discrepancy is standing in front of the patient. The equivalent in a commercial pipeline is pushing the check into the source application rather than the warehouse, which is the only place where the fault can be corrected instead of patched.
A batch that passes all seven checks can still be wrong. Every check described here measures conformance to a written standard: the shape, the completeness, the uniqueness, the range. None of them measures truth. If a currency conversion upstream multiplied every price by 100, the column is still fully populated, still unique on its key, still inside a plausible range if the range was set generously, and still completely wrong.
Two things close that gap and neither is a check. The first is reconciliation against an independent source: compare the total the warehouse reports against the total the source system reports, and investigate the difference rather than the value. The second is a consumer who is expected to say something when a number looks wrong, and a route for them to do it that is faster than rebuilding the report themselves. Quality control catches the faults that have a signature. Reconciliation and an alert consumer catch the ones that do not.
Quality control also does not fix the source. Correcting a value in the warehouse leaves the fault in the system that produced it, so the same batch fails again tomorrow. The check tells you which producer to go to. Going there is a different piece of work and it belongs to the producing team, not the data team that found it.
Quality control in data management earns its name when a failing check has a consequence. Write the acceptance specification so there is a standard to fail against. Inspect the batch at the release point so the consumer is not the detector. Decide the disposition in advance so the answer does not depend on who is awake. Record the measured value so the next threshold is derived rather than guessed. Four practices, and between them they turn a set of dashboards into something that actually stops bad data.
The shortest version, if you are starting from nothing: pick the one dataset whose failure would embarrass you most, fill in the six specification fields for it this week, add the seven release point checks with loose thresholds, and store the numbers. That is a working control on your most important table inside a fortnight, and it is a better starting position than a platform rollout that covers everything and stops nothing. If you would rather see the checks, the lineage and the incident workflow running against your own tables, book a walkthrough with the Decube team.
Quality control in data management is the systematic inspection of a dataset against a written standard, carried out before that dataset is released for use, to confirm it is accurate, complete, consistent and timely enough for the decisions it feeds. It runs as four activities together: profiling to learn what the data contains, cleansing to correct what is wrong, validation to reject what does not conform, and monitoring to notice when any of it changes. The word control is what separates it from reporting: a failing check has to be able to stop the data from reaching a consumer.
Quality control inspects a specific batch of data against a written standard before it is released, and produces a pass or fail verdict on that batch. Quality assurance changes the process so the fault stops occurring, and produces changed pipelines, schemas, contracts and source system rules. Quality control runs at the point data moves. Quality assurance runs at design and review time. A team doing only quality control keeps catching the same fault every week; a team doing only quality assurance ships whatever the process happens to produce.
The seven measures that belong at the release point are: row count against the trailing median for the same weekday, freshness of the maximum event timestamp, schema conformance on column names and types, null rate on the columns named in the specification, uniqueness of the business key, referential coverage of foreign keys against the parent table, and accepted values in coded columns. Each one needs a pass value derived from the last 90 days of observed data rather than a round number, a named owner who answers when it fails, and a disposition saying whether the batch is blocked, quarantined or released with a notice.
QC in data management is quality control: the checks that run on a batch of data before it is published to the people who use it, and the decision about what happens to the data that fails. QC is distinct from QA, which is quality assurance and covers the design of the process itself. In an operating data team QC is a concrete artifact rather than a principle: an acceptance specification per dataset, checks running between load and publish, a named owner per check, and one of three dispositions applied when a check goes red.
In data analysis quality control runs before the analysis rather than inside it. The dataset is profiled to establish what it contains, inspected against an acceptance specification at the point it is loaded, and released to the analyst only when it passes. The analyst then works on a dataset with a known state rather than discovering the state through the results. The failure mode when quality control is skipped is not a broken analysis, which is visible, but a plausible analysis built on a partial load, which is not.
Database quality control is the same discipline applied at the database level rather than the pipeline level, and it leans on constraints the database itself can enforce: not null constraints on mandatory columns, unique constraints on business keys, foreign key constraints for referential integrity, and check constraints for accepted values and ranges. A constraint is stronger than a scheduled check because it refuses the write rather than reporting on it afterwards. Constraints cannot express everything, so they are the first layer and the seven release point checks are the second.
Quality control in clinical data management is the same four practices under a regulator, with three differences. The acceptance specification is the data management plan and the edit check specification, agreed before enrollment and changed only by controlled amendment. The release point is database lock rather than a nightly batch. And the disposition options are narrower, because releasing a dataset with a written notice is generally not available, so a discrepancy becomes a query raised against the site, answered and resolved before lock. The audit trail showing every changed value, who changed it and why is mandatory rather than optional.
Data quality oversight is the accountability layer above the checks: who is answerable for a dataset, how often the check results are reviewed, and what happens when a failure is not resolved inside the agreed response time. Oversight adds no new check; it is the reason a failing check produces an action instead of a notification. In practice it is three things: a named owner per dataset rather than a team alias, a fixed review of the stored measurement series, and an escalation route when the owner does not respond.
Before an agent reads a table autonomously, four things have to exist. An acceptance specification for every table the agent may read, so there is a written definition of what good means. Release point checks on those tables, so a batch the agent reads has been inspected rather than merely loaded. Classification of sensitive columns, so the agent is refused access to fields it should not see rather than trusted not to use them. And lineage coverage, so when the agent produces an answer you can trace which columns it came from. An agent has no way to notice that a number is wrong, which is why the inspection has to happen before the data reaches it rather than after.
It depends on the check. Schema, freshness and row count checks are table level and cost one monitor per table regardless of how many columns the table has. Null rate, uniqueness, accepted values and range checks are column level and are counted per column. That is why the column selection rule matters commercially as well as operationally: specify a column only if a wrong value in it changes a number somebody acts on, which on a typical fact table is eight to fifteen columns rather than two hundred. Ask any vendor to price against your real column selection rather than your table count, because the two numbers differ by an order of magnitude.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)