Data quality monitoring levels 1 and 2: A practical guide to getting started

Data quality monitoring is the continuous evaluation of data against defined expectations for completeness, validity, consistency, uniqueness, and range, paired with the rules, ownership, and escalation paths that turn a detected problem into a resolved one. Most organizations building a monitoring program today are working through their first two maturity levels: Ad-hoc Action and Informed Execution, which is what this piece covers: the specific rule types, monitoring discipline, and governance basics required to get through them without building something you have to tear down later.

Enterprises moving real workloads onto AI have run into an uncomfortable dependency. The performance of a model, the reliability of an agent, and the defensibility of an automated decision all rest on the condition of the data feeding them. Data quality is no longer a governance nicety. It’s the precondition for any system that acts without a person checking its inputs first. When that data carries silent defects, the failure doesn’t stay contained in a stale dashboard. It propagates into predictions, customer interactions, and regulatory filings at machine speed, and nobody notices until the output is already in front of a customer or an auditor.

For most of its history, data quality monitoring lived inside governance programs and served human readers of reports. That framing no longer covers what the work has to carry, because AI enablement, reliable analytics, regulatory compliance, and enterprise modernization now all depend on data that can be trusted without a person checking it first.

Most data leaders aren’t starting a monitoring program from zero maturity or trying to leap straight to enterprise scale. Ataccama’s data maturity model for data management programs runs four levels: Ad-hoc Action, Informed Execution, Targeted Engagement, and Systematic Operation – tracking a program’s progression from a small, centralized team defending core data assets (Horizon 1) through enabling broader data culture (Horizon 2) to full enterprise adoption (Horizon 3). Most organizations building out data quality monitoring today are working through the first two levels, and that’s the honest starting point for this piece: what Ad-hoc Action and Informed Execution require in practice, specifically for the rules and monitoring discipline that make the rest of the model possible.

Why most programs stall before they start

Most quality programs stall for structural reasons rather than technical ones. They begin reactively, triggered by a high-profile error or a leader who stops believing a dashboard, and they stay reactive because remediation competes with everything else on a data team’s plate. Ownership is the second fault line: when no one is formally accountable for a dataset, a detected issue has nowhere to go, and rules accumulate without anyone maintaining the logic behind them.

Fragmented governance compounds both problems. Rules written in one business unit duplicate rules written in another, naming conventions diverge, and the same customer record gets validated three different ways depending on which team touched it last. A documented data quality framework is what prevents this fragmentation from compounding as more teams get involved. These weaknesses were tolerable when the consumer of the data was a human analyst who could apply judgment and catch an obvious anomaly. They stop being tolerable the moment the consumer is a model in training, a retrieval system answering a customer, or an agent acting without a person in the loop.

Level 1, Ad-hoc Action: building visibility with a small number of rules

The foundational stage of a monitoring program isn’t about coverage or automation. It’s about surfacing and responding to obvious issues quickly, using a small number of high-value rules applied to the data that matters most, the critical data elements (CDEs) tied directly to business processes.

Four control types catch the majority of damaging defects with very little engineering effort:

• Completeness. Are key fields populated? A missing identifier breaks downstream processing whether a human or a model consumes it.
• Validity. Do values conform to an expected format, such as a date pattern or postal code mask?
• Uniqueness. Are there duplicates in primary identifier fields? A single duplicated record can double-count revenue or split a customer in two.
• Range checks. Do numerical values fall within acceptable thresholds? This surfaces the kind of outlier that signals an upstream entry error.

Each control turns an implicit human assumption into an explicit, checkable condition, which matters because a model can’t infer that a field should never be null. It will learn the null as signal. Foundational controls are the first prerequisite for letting any automated system rely on the data at all.

The most reliable starting point for rule design is logic that already exists. Most organizations have manual checks living inside reports, spreadsheets, and the heads of experienced analysts, and porting that logic into formal rules captures institutional knowledge that would otherwise stay undocumented. Rules that align to known error hotspots, and that carry a plain-language description of what they check and why, build the organizational buy-in that a monitoring program needs to survive its first few months.

Monitoring at this stage should be light-touch but disciplined: batch checks aligned to data loads, violations logged somewhere shared, and thresholds set deliberately enough to avoid the alert fatigue that quietly kills adoption. A breach in a regulated field should escalate immediately; a cosmetic inconsistency can wait for a scheduled review. Getting that distinction right, along with early governance basics like a shared rule inventory and a naming convention that prevents duplicate rules, is what separates a Level 1 program that compounds from one that has to be rebuilt in a year.

Moving to Level 2: the deeper-versus-wider decision

The pivot from foundational to proactive monitoring turns on one recurring decision: go deeper or go wider. Going deeper means adding more sophisticated, conditional, or cross-table rules to datasets already under monitoring. Going wider means extending coverage to new datasets, domains, or business units that have never been instrumented. Doing both at once dilutes the program, so the choice has to be governed by a value or risk score assigned to each data asset, one that factors in business criticality, history of quality incidents, stewardship maturity, and regulatory exposure. A dataset feeding a regulated filing with a history of incidents outranks a stable internal table, regardless of which team asks first.

Level 2, Informed Execution: what proactive monitoring actually requires

At Level 2, monitoring moves into data pipelines, so validation happens as data moves rather than after it lands — the same shift-left principle that governs modern data contract design. Alerts become threshold-based and escalating. Results become accessible through dashboards or catalog tools, so a steward sees a dataset’s quality status at the moment they go to use it.

A handful of metrics start to matter here: the share of datasets under active monitoring, the average time to resolve a violation, and the rate of recurring violations, which tells you whether root causes are being fixed or just patched.

Rules also need a lifecycle at this stage rather than a permanent, unversioned existence. As the rule library grows, reusable logic (an email format check, for instance) needs to be separated from context-specific business rules, and every rule needs a standard set of metadata, what it checks, why it matters, who owns it, what it depends on, so that a library serving a growing number of stakeholders doesn’t collapse into technical debt. Change control matters just as much: requiring a change description and expected impact before any edit, and notifying downstream consumers when a key rule changes, is what prevents the silent edits that quietly erode trust in a program.

Governance at Level 2 formalizes ownership into two roles: a business owner who defines what a rule should do, and a technical steward who implements and maintains it, with service levels attached to violations so ownership becomes a commitment rather than a label. This is also the point where data quality and data observability start working together: observability catches the freshness and schema-drift issues a fixed rule set would miss, while the rules keep validating whether the data is actually correct.

Where this goes next

Level 1 gets a program off the ground. Level 2 is where it becomes something an enterprise can actually rely on for regulatory reporting, customer-facing analytics, and, increasingly, the data feeding AI systems that act without a person in the loop. Getting there requires more than knowing the four rule types and the two ownership roles. It requires the operational detail: how to structure a rule so someone who didn’t write it can maintain it, how to sequence a rollout across the first ninety days, and how to build the governance scaffolding that survives audits.

That’s the part we put in the guide, not the blog.

Download the Data Quality Monitoring & Rules Management guide for the Level 1 and Level 2 rule template (the exact fields every rule needs to stay auditable), the governance framework for rule lifecycle and change control, and a structured breakdown of what to prioritize in your first 90 days.

If your program is further along toward Targeted Engagement or Systematic Operation, we’re happy to compare notes on what federating best practices across departments looks like in practice.