Data quality is always purpose-dependent

Data is not abstractly good or bad. Its quality depends on whether it can support a concrete task at an acceptable level of risk.

A dataset can be complete and still be unsuitable. A customer list may contain every record while outdated contact details cause failed deliveries. A catalogue may be current, yet inconsistent units make quantity comparisons unreliable. An image collection may be technically intact while failing to represent later operating conditions.

Data quality is therefore neither a single score nor a permanent badge. It describes fitness for an intended purpose. The same collection may be sufficient for a rough trend analysis, unsuitable for an individual credit decision and distortive for training a particular model.

Purpose comes before cleaning

Teams often begin with duplicates, missing fields and formatting errors. These checks are useful, but they do not define "good enough". Before cleaning, five questions matter: Which task will the data support? What decision follows? Who or what is affected? Which errors are reversible? Which consequences are unacceptable?

Incomplete sources may be acceptable for informal ideation. An automated payment requires unique identifiers, correct amounts, currencies and approval states. Medical or employment-related decisions demand much stronger scrutiny of relevance, representativeness, bias, timeliness and human control.

Quality is therefore a risk decision. The greater the possible harm and the harder the correction, the stronger the data, assurance and escalation paths must be.

Quality dimensions form a selection menu

A purpose-specific profile selects the dimensions that actually influence the outcome:

1 · Accuracy: Does a value adequately describe the relevant reality? Accuracy is not the same as formal validity.

2 · Completeness: Are the fields, cases and periods required for the purpose present?

3 · Timeliness: Do capture time and validity period match the task?

4 · Consistency: Do values, definitions and units agree within and across systems?

5 · Uniqueness: Are real entities identified without false merging or duplication?

6 · Validity: Do type, format, range and category follow defined rules?

7 · Integrity: Do keys, relations and derivations remain complete and traceable?

8 · Representativeness and coverage: Do data cover relevant groups, situations, edge cases and operating conditions?

9 · Label quality: Are classes defined professionally, applied consistently and disagreements resolved transparently?

No dimension dominates every use case. A delivery address may depend more on freshness than historical completeness. Longitudinal analysis requires history. For a classifier, rare but consequential edge-case coverage may matter more than average error.

From quality objective to testable rule

"The data looks clean" is not a control. A requirement becomes operational when it names a population, metric, threshold, measurement frequency and response.

rule_id: customer-contact-freshness
purpose: service_notification
population: active_customers
dimension: timeliness
metric: share_verified_within_180_days
threshold: ">= 0.97"
severity: high
on_failure: block_automated_dispatch
owner: data_steward_customer

This rule explains what is tested, when the outcome becomes unacceptable and what happens next. A useful report records the observed value, threshold, time, affected records, deviation and accountable role.

Metrics require denominators and context. "95 per cent complete" is meaningless without required fields, population and distribution. If all missing values concern a small but highly affected group, the average conceals the relevant risk.

Averages can hide poor data

Aggregate indicators matter, but local failures can disappear inside them. Quality should therefore be assessed across relevant groups, sources, periods, regions, devices or process variants. These slices follow the task and plausible harm patterns rather than convenience.

Representativeness does not mean every dataset must perfectly mirror a population. The intended population and operating conditions determine the target. Deliberate oversampling of rare safety cases may be appropriate even though the training distribution differs from everyday frequency. Training, calibration and evaluation must then account for that difference explicitly.

Training, testing and knowledge bases need different controls

Quality purpose changes across the AI lifecycle. Training data needs learnable signal and relevant variation. Validation data supports model and threshold selection. Test data should enable independent evaluation. Overlap or information leakage can make results look artificially strong.

For retrieval and generative systems, the focus shifts. A knowledge base needs valid sources, stable provenance, permissions, useful segmentation and update processes. Completeness does not mean uploading every document; it means providing the necessary and permitted sources for the defined knowledge space.

Synthetic data is not automatically high quality either. It may improve coverage or supplement sensitive originals, but can amplify errors, unrealistic patterns or model bias. Provenance, generation method and fitness require separate assessment.

AI recognises patterns but does not define truth

AI can flag outliers, suggest duplicate records, normalise units, identify missing categories and report unusual distributions. These outputs remain hypotheses. An extreme value may be a sensor fault or a rare real condition. Similar names may refer to one person or two.

Every automated correction therefore needs a trace: original value, proposal, method, model or rule version, timestamp, rationale and approval. Low confidence or high consequences should trigger escalation rather than silent overwrite.

A robust architecture separates detection, decision and change. A model detects the anomaly. A professional rule or accountable person determines its meaning. Only then is a corrected, versioned value created.

Quality is a continuous control loop

A cleaned dataset does not remain clean. Sources change, processes introduce new errors, categories are redefined and reality drifts. Controls must operate during capture, transformation, approval and use.

The loop is: define expectations, measure, investigate deviation, correct the cause, validate the effect and update the rule. Not every deviation requires the same response. Records may be blocked, labelled, reviewed manually or used with a limitation.

Good data quality is not perfection. It means that requirements are justified, measurements are reproducible, uncertainty is visible and failure consequences are controlled. This turns cleaning from a one-off technical task into an accountable system capability.

Worksheet: Build a purpose-specific quality profile

Choose a dataset and a concrete AI or analytics use case. Work with at least ten real or realistic records.

1. Define purpose and decision. Describe the outcome, affected people or processes and the worst plausible consequence.

2. Bound the population. Specify cases, periods and operating conditions that must be covered.

3. Write five rules. Each includes dimension, population, metric, threshold, frequency, response and accountable role.

4. Test in slices. Assess at least two relevant subgroups separately and compare their values with the aggregate.

5. Control AI proposals. Let a system suggest anomalies or duplicates. Accept no change without professional rationale and a recorded trace.

6. Make a release decision. For each rule choose accept, use with limitation, review manually or block.

All materials to download — the topic overview and the worksheet:

Scope: The cited ISO standards provide models and processes; mentioning them does not claim certification. Article 10 does not apply universally to every AI application. Quality objectives, thresholds and assurance intensity must be derived from purpose, risk, affected people and operating context.

Sources and professional scope