Data Quality Is a Computational Property

Abstract

Data quality is often organised as a terminal inspection: after ingestion and transformation, a suite of checks decides whether the dataset is good. This essay argues that quality is not an external label attached to a finished product but a computational property produced, transformed, and sometimes degraded at every stage. It develops a multidimensional quality model, distinguishes intrinsic, contextual, representational, and process quality, and formalises quality propagation through tasks. It addresses uncertainty, thresholds, fitness for purpose, and the dangers of composite scores. The philosophical claim is that “correct data” has no universal meaning independent of use. Quality must be specified relative to the claims a dataset is expected to support, while still preserving objective constraints such as identity, units, and temporal coherence.

1. Quality is produced, not inspected

A final validation step can detect some defects but cannot repair an architecture that has already discarded identity, precision, provenance, or timing. Quality emerges from capture, transport, mapping, computation, and publication.

Let a dataset at stage $i$ be $D_i$, produced by task ${\tau }_i$:

Associate a quality state $Q_i$ with each dataset. Quality propagation is

where $C_i$ is context. A transformation may improve standardisation while reducing granularity; improve completeness through imputation while increasing uncertainty; reconcile identities while introducing false matches. Quality is not necessarily monotone.

The platform must therefore record how each task changes the quality profile, not only whether final checks pass.

2. Dimensions rather than a single score

A quality vector may include

representing completeness, validity, accuracy, timeliness, identity integrity, provenance, representational coherence, and explainability. Additional dimensions may be needed for uniqueness, consistency, coverage, or bias.

Collapsing the vector into one score

is useful for monitoring but dangerous for decision. A catastrophic identity failure can be hidden by high completeness. Some dimensions are non-compensatory. A safer model combines hard constraints with weighted soft quality:

The set $H$ contains qualities that must not be traded away for the use case.

3. Fitness for purpose

A dataset can be adequate for one purpose and unsafe for another. Near-real-time operational monitoring may tolerate some missing descriptive fields while requiring freshness. Research may tolerate delay while requiring stable cohorts and detailed provenance. Billing may prioritise completeness and legal coding. Safety decisions may require high identity confidence and explicit uncertainty.

Let purpose be $u$. Quality is evaluated as

where $W_u$ specifies dimension importance and minimum constraints. This does not make quality subjective in the casual sense. It makes evaluation conditional on the claim and consequence.

The philosophy of measurement supports this view. Measurement is never simply the presence of a number; it is a relation among procedure, construct, scale, and use. A dataset’s fitness cannot be separated from the questions asked of it.

4. Structural validity and semantic validity

Structural validity checks whether values conform to types, formats, lengths, and domains. Semantic validity checks whether values make sense in relation to the represented phenomenon.

A timestamp can be syntactically valid and occur before the entity’s creation. A unit can belong to an allowed code set and be incompatible with the measure. An identifier can be non-null and point to the wrong person.

Semantic constraints often involve relations:

These constraints should reside near the Data Object contract. If they are implemented separately in every report, quality becomes inconsistent and invisible.

5. Accuracy, truth, and observable proxies

Accuracy is the most desired and least directly measurable dimension. To know whether a value matches reality, the platform needs a trusted reference or independent observation. Frequently it has neither.

Quality systems therefore use proxies: agreement across sources, plausibility bounds, reconciliation totals, manual samples, or process conformity. Let latent true value be $z$ and observed value $x$. Accuracy concerns

but when $z$ is unknown the platform estimates confidence from evidence $E$:

This probabilistic humility is preferable to labelling unchecked data “accurate.” Quality metadata should distinguish measured accuracy, inferred confidence, and unverified assumption.

6. Quality rules as versioned computations

A quality rule is a computation with scope, severity, threshold, and consequence:

The predicate $p$ may operate at record, partition, dataset, or cross-dataset level. Threshold $\theta$ turns observations into policy. A null rate of 0.2% is not inherently good or bad; the rule determines admissibility for a purpose.

Rules must be versioned because expectations evolve. A new mandatory field should not make old historical data appear defective under a rule that did not exist. Results should record rule version and evaluation time.

Quality rule lineage also matters. When a metric changes because a quality filter changed, the platform should expose the dependency. Otherwise quality governance silently rewrites business results.

7. Quality propagation and uncertainty

Transformations can propagate uncertainty. Suppose $y=f(x_1,\dots ,x_n)$ and each input has uncertainty ${\sigma }_i$. Under differentiability and simplifying assumptions, propagated variance can be approximated by

Not all data quality is numerical, but the principle generalises: derived outputs inherit limitations from inputs and introduce new ones through transformation.

A canonical mapping with confidence 0.8 should not produce an output labelled simply “standardised.” An identity match with probabilistic confidence should propagate that status to downstream analysis. Quality metadata must travel with the data or remain accessible through lineage.

The platform should resist the cultural tendency to remove uncertainty at each layer for the sake of clean presentation.

8. Quarantine, degradation, and continuity

Quality failure need not force total pipeline failure. Records can be partitioned:

with disjoint subsets and conservation checks. Dataset-level quality can produce degraded publication with explicit warnings when policy permits.

The disposition depends on consequence. A malformed optional note may be quarantined while numeric observations continue. An ambiguous identity may require blocking because misattribution is worse than delay. Quality architecture therefore encodes risk priorities.

Continuity must not become an excuse to publish known defects invisibly. Degraded outputs should carry status, affected dimensions, and expiry or remediation expectations.

9. Quality as an organisational feedback loop

Repeated defects indicate more than bad records. They reveal source-process problems, unclear ownership, inadequate interfaces, or misaligned incentives. Quality metrics should therefore feed upstream improvement.

Let defect rate for rule $r$ and producer $p$ be $d_{r,p}(t)$. Monitoring trends and remediation time can identify structural issues. Yet quality metrics can also distort behaviour if used punitively. Producers may optimise fields to pass checks without improving meaning.

A healthy quality culture treats defects as evidence about the socio-technical system. The objective is not to assign shame but to reduce recurrent ambiguity and failure. Ownership means the capacity and obligation to improve the process, not merely receive alerts.