The six quality dimensions that support a data program

Every governance program arrives, sooner or later, at the same question: is the data good? The question looks simple and isn't. "Good" for whom, for which decision, with what tolerance. Without breaking the word down into measurable dimensions, the discussion becomes opinion, and opinion doesn't go into an indicator.

The six dimensions below are the ones that support most of the programs we have seen work. None of them requires a paid tool to get started: all of them fit in a SQL query over the base itself.

Completeness

It measures the absence of a value where a value is required. Don't confuse it with an empty field: an optional field left blank is not incompleteness, it is a choice. The useful measure is the percentage of records that have all the fields required by the domain rule.

The common mistake is measuring completeness against the schema instead of against the business rule. The database accepts a supplier without a CNPJ (Brazil's company registration number); the payment process doesn't.

Uniqueness

It measures how many times the same real-world entity appears as distinct records. It is the dimension that hurts the most and hides the most, because a duplicate is rarely identical: an accent changes, an abbreviation, a digit.

Start with the key the business recognizes as unique: CNPJ for the supplier, employee ID for the employee, barcode for the material. Where no key exists, uniqueness is not a data problem, it is a pending modeling decision.

Validity

It measures conformance with format and value domain. A CEP (Brazilian postal code) with eight digits, a UF (Brazilian state code) among the 27, a date that exists on the calendar, a status among those provided for. It is the easiest dimension to automate and the first one that should go into record creation, not into the audit.

Validity doesn't guarantee truth. A formally valid CNPJ may not exist at the Receita (Receita Federal, Brazil's tax authority). That is accuracy, not validity.

Consistency

It measures whether the same fact matches across systems and across fields. The customer marked as inactive in the CRM has an open order in the ERP. The product has a unit of measure of "box" and a unit weight in grams.

Consistency is the dimension that reveals a process problem, not a typing problem: when two systems disagree, there are almost always two owners and no rule about who wins.

Accuracy

It measures the distance between the data and the fact it represents. It is the hardest dimension, because it requires an external source of truth: a query to the Receita, a physical inventory count, a call to the customer.

That is why accuracy is rarely measured on 100% of the base. Choose a statistically defensible sample and measure on a fixed schedule. A measured sample is worth more than a promised census.

Timeliness

It measures whether the data reflects the current state of the fact. An address that was correct in 2019 is a wrong address today. The practical measure is the age of the last update event compared against the expected rate of change of that attribute.

An address changes; a CPF (Brazil's individual taxpayer number) doesn't. Defining the expectation per attribute avoids the waste of re-creating what doesn't change.

How to turn this into an indicator

Choose a domain, not the whole base. For each dimension, write a query that returns a number between 0 and 100 and a list of the records that failed. Publish the number and hand the list to the owning area.

The number serves to track the trend. The list is what makes the work happen: an indicator without an exception list produces a meeting, not a fix.

Set the target with the area, not for the area. A completeness of 92% may be excellent in one domain and unacceptable in another; whoever knows the difference is whoever answers for the process.