Data Quality in Context

Most data-quality conversations have already gone wrong before you arrive. Someone says the data is "clean," someone else says it "can't be trusted," and nobody has said for what. As a Data Architect, your value is not simply measuring quality. It is helping stakeholders make the argument specific enough that a decision can be defended.

In this lesson, you will learn to:

• Distinguish accuracy, completeness, consistency, timeliness, validity, and uniqueness
• Judge which dimensions are material to a named consumer decision
• Explain why a single overall quality score can hide consequential risk

This lesson takes apart the comfortable assumption that "quality" is a property a dataset either has or lacks.

Ask three stakeholders what a quality problem looks like and you may get three incompatible stories. That is because "bad data" collapses at least six distinct failures into one phrase, and each can undermine a different decision.

Notice how easily these get confused. A record can be perfectly valid and completely inaccurate. Placeholder dates of birth can pass a format check and fail reality. If you cannot name which failure you are looking at, you cannot name who is harmed by it.

Here is the question that should make you uncomfortable: if quality is defined relative to a stated use, what does "this dataset is good" mean when no use has been stated?

It means very little. Fitness for purpose is not a caveat attached to a quality assessment. It is what makes the assessment possible. The same dataset can be fit for exploratory churn-model work, where completeness gaps and some inaccuracy may be tolerable because the output is a hypothesis, and unfit for a mandatory customer communication, where duplicates can mean people receive two notices and unverified addresses can mean people receive none.

In this conversation, Simone leads a domain team whose dataset feeds two very different decisions, and Natalie, the Data Architect, helps her see why one clean verdict cannot cover both.

> **Simone:** The dataset is accurate. We reconcile it every month, so it is good. > > **Natalie:** Good for which decision? An internal trend chart and a customer refund run are not asking the same thing of it. > > **Simone:** Does that change the answer? Accurate is accurate. > > **Natalie:** For the trend chart, a few stale or missing rows barely move the shape. For the refund run, one duplicated account pays someone twice and one missing account pays no one. Same data, different stakes. > > **Simone:** So a single "it is good" was never really answering anyone's question.

Natalie does not dispute the reconciliation. She asks which decision the verdict is for, which is much harder to wave away.

So why do organizations keep building a single overall quality score? It is legible to executives, and it can make everyone stop arguing. Both are reasons to distrust it.

A composite score attached to no particular use answers no one’s actual question. Worse, it averages away exactly the signal that matters: a dataset scoring 94% can be perfectly safe for one consumer and legally dangerous for another, and the number hides which. Aggregation is not neutral here. It can favor dimensions that are easy to measure over the ones that carry consequence.

The takeaway is this: whether data is good enough is not an intrinsic property of a dataset. It is a relationship between the data and a stated decision, and the six dimensions are how you make that relationship arguable. Two quick checks come first to sharpen your grip on the dimensions and the score problem. Then you will take this into a live conversation with a domain lead convinced that the dataset is good enough for everything. Before that, ask yourself: whose decision would you need to name before you could honestly call any dataset you work with "good"?