Data Quality Part 1: Beyond Accuracy — What "Good Data" Really Means When AI Is on the Line

Most executives think data quality means one thing: is the number right? Three decades of research — and a string of nine-figure disasters — say it's actually at least seven different things, and AI is now scaling whichever one your organisation got wrong.

In Part 1 of our Data Quality in the AI Era series, James starts skeptical. Surely "is the data accurate" covers it? Why is this being made harder than it needs to be? Sarah walks him — and the listener — through what data quality actually is, the seven dimensions that matter for enterprise AI, and the killer distinction that explains most of what goes wrong: valid is not the same as accurate.

What we cover:

• Why "we cleaned the data, it's accurate now" has been doing damage for thirty years
• The seven dimensions of data quality — and why a single quality score is dangerous
• Public Health England: 15,841 COVID cases lost because an Excel file silently truncated rows
• NASA Mars Climate Orbiter: a $327M spacecraft lost to a unit mismatch that was perfectly valid
• Citigroup / Revlon: how three fields, six eyes, and one missing range check became an $894M wire transfer
• A heavy-industrial safety story where the data wasn't catastrophically wrong — it was catastrophically ambiguous
• Why AI doesn't inherit these problems gently — it scales them, in a tone of voice that sounds correct
• A teaser for Part 2: the Robodebt case, and the one question that would have prevented it

For executives, senior technology leaders, and data leaders trying to get real value from AI investment — without funding it on a foundation nobody has actually inspected.

"Polished on the surface, shaky underneath." — James

Episode length: ~21 min
Series: Data Quality in the AI Era — Part 1 of 2

References:

• The MIT Total Data Quality Management Program — https://web.mit.edu/tdqm/www/about.shtml
• MIT Sloan Management Review, Wang & Strong (1996), "Beyond Accuracy: What Data Quality Means to Data Consumers" — https://doi.org/10.1080/07421222.1996.11518099
• DAMA UK Working Group, "The Six Primary Dimensions for Data Quality Assessment" (2013) — https://www.sbctc.edu/resources/documents/colleges-staff/commissions-councils/dgc/data-quality-deminsions.pdf
• ISO/IEC 25012:2008, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) —  https://www.iso.org/standard/35736.html
• Sambasivan et al., "Everyone wants to do the model work, not the data work: Data Cascades in High-Stakes AI", CHI 2021 — https://research.google/pubs/everyone-wants-to-do-the-model-work-not-the-data-work-data-cascades-in-high-stakes-ai/
• IBM Institute for Business Value, "2025 CDO Study: The AI multiplier effect" — https://www.ibm.com/thought-leadership/institute-business-value/en-us/report/2025-cdo
• BBC News, "Covid: 16,000 coronavirus cases missed in daily figures after IT error" (5 October 2020) — https://www.bbc.com/news/uk-54422505
• NASA, Mars Climate Orbiter Mishap Investigation Board Phase I Report (1999) — https://llis.nasa.gov/llis_lib/pdf/1009464main1_0641-mr.pdf
• Citi cites human error in accidental $900M transfer —  https://www.bankingdive.com/news/citi-cites-human-error-in-accidental-900m-transfer/584156/
• Royal Commission into the Robodebt Scheme, Final Report (7 July 2023) — https://robodebt.royalcommission.gov.au/publications/report

Related episodes:
Episode 1 — Why Data Observability Matters Before AI Scales

Transcript

SPEAKER_01 0:06

Welcome back to AI Beyond the Hype. I'm James.

SPEAKER_00 0:10

And I'm Sarah.

SPEAKER_01 0:11

Casting our minds back to episode one on data observability, we left things on a line we both quite liked, which was make the data observable before you make the AI ambitious.

SPEAKER_00 0:23

We did like that line.

SPEAKER_01 0:24

We did. So I want to pull on it today, because if we're saying make the data observable, the obvious next question is, observable of what? Exactly? What are we actually looking at when we look at data?

SPEAKER_00 0:37

Hmm, yeah, and that's a much bigger question than people expect it to be.

SPEAKER_01 0:41

Right, and here's where I'm going to be the difficult one for a few minutes. Because I think most executives, if you ask them what good data means, would say something like, is the number right? Is it accurate? And honestly, that sounds like a reasonable place to land.

SPEAKER_00 0:57

It does sound reasonable.

SPEAKER_01 0:59

So convince me it isn't. Because to aboard, we cleaned the data. It's accurate now. That's a sentence that sounds like a job finished.

SPEAKER_00 1:07

Yeah, and that's the problem. Because that sentence has been doing a lot of damage for about 30 years now.

SPEAKER_01 1:14

Strong opening.

SPEAKER_00 1:16

Sorry. That came out more dramatic than I meant. But there's a reason for it. There was a piece of research at MIT in the mid-90s, the Total Data Quality Management Program, that basically settled this question. What they showed, after a lot of empirical work, was that data quality isn't accuracy. It's fitness for use. And fitness for use is multidimensional.

SPEAKER_01 1:42

Okay, translate that.

SPEAKER_00 1:44

It means a dataset can be highly accurate and still completely useless for the thing you want to do with it. It can be accurate but stale. It can be complete but inconsistent. It can be valid but semantically wrong. It can be current but inaccessible. And different uses need different things. A real-time fraud model lives or dies on freshness. A regulatory report lives or dies on lineage. A machine learning training set lives or dies on whether it actually represents the population you're going to make predictions about.

SPEAKER_01 2:20

So there isn't one number called data quality that you can put on a slide.

SPEAKER_00 2:24

There really isn't. And the moment you try, you start optimizing for whatever's easiest to measure. And that almost never matches what your business actually depends on.

SPEAKER_01 2:36

Right, okay. I can feel my this is overengineered instinct softening, but I'm not all the way there yet. How many of these dimensions are we talking about?

SPEAKER_00 2:45

The consensus across all the major frameworks Wang and Strong, ISO, Dharma UK, the healthcare crowd with the Khan framework is a core of seven.

SPEAKER_01 2:57

Seven?

SPEAKER_00 2:58

Accuracy, completeness, consistency, timeliness, validity, integrity, and uniqueness. And then, depending on the use, you add things like accessibility, relevance, and believability.

SPEAKER_01 3:13

Hmm. Seven. Plus a few more. Okay, I am going to push back gently here because if I take this to a CFO, I need to make seven feel like something other than a list.

SPEAKER_00 3:26

That's fair. And actually, the easiest way to make it real isn't to define them, it's to show you what each one looks like when it fails. Because they fail very differently.

SPEAKER_01 3:37

Alright, let's do that. Pick a good one to start.

SPEAKER_00 3:40

Completeness. This one's easy to underestimate. Public Health England, 2020. Right in the middle of the pandemic, they had a pipeline transferring positive COVID test results into the contact tracing system. The intermediate format was an old Excel file, the kind that maxes out at around 65,000 rows.

SPEAKER_01 4:01

Oh no.

SPEAKER_00 4:02

Yeah. And because each test result spanned several rows, the real cap was around 1,400 tests per file. The daily volume blew through that, and the extra results were just silently truncated. No error, no alert. Between the 24th of September and the 2nd of October, 15,841 positive cases never made it into test and trace.

SPEAKER_01 4:27

15,000 cases that should have triggered contact tracing. That didn't.

SPEAKER_00 4:32

That didn't. The Health Foundation modeled the onward transmission. It was bad. And the dimension that failed there was completeness. Records that existed upstream were missing downstream. The control that would have caught it is genuinely embarrassing in retrospect. It's a row count. You count what went in, you count what came out, you compare them.

SPEAKER_01 4:58

That's not a sophisticated check.

SPEAKER_00 4:59

It's not. It's a check a graduate could write in their first week. But nobody owned the comparison.

SPEAKER_01 5:05

That's the bit that always gets me. The control isn't clever, it's just absent.

SPEAKER_00 5:10

Almost every one of these stories is like that.

SPEAKER_01 5:14

Okay, give me a different one. Different dimensions.

SPEAKER_00 5:17

NASA Mars Climate Orbiter, 1999. $327 million spacecraft. It was lost on orbital insertion because Lockheed Martin software was emitting thruster values in pound four seconds, and the JPL navigation team was reading the file assuming Newton seconds.

SPEAKER_01 5:36

Imperial versus metric.

SPEAKER_00 5:38

Exactly. The conversion factor is about four and a half. So for 10 months of transit, every single thruster firing was being underestimated by that factor. The error compounded, and on arrival the spacecraft came in about 170 kilometers lower than planned and didn't come back out.

SPEAKER_01 5:57

And let me try this. The values themselves weren't wrong, were they? They were correct in pound four seconds.

SPEAKER_00 6:04

That's exactly right. That's the whole point. The values were perfectly valid. They obeyed every format rule in the Lockheed system. The file passed every check on the way out. They were just semantically wrong for the consumer.

SPEAKER_01 6:19

So valid is not accurate.

SPEAKER_00 6:21

Valid is not accurate. This is the single most important distinction in this whole topic. Validity means the data follows its own rules. The format is right, the type is right, the value is in range. Accuracy means it matches the real world. You can be 100% valid and 0% accurate. There's a famous Australian case we're going to come back to that's exactly that.

SPEAKER_01 6:49

Hold that one. Because that distinction, valid versus accurate, that's the one I want every executive to walk away with. It explains so much. Because when a team reports 98% data quality, they're almost always reporting validity, aren't they?

SPEAKER_00 7:05

Almost always. Validity is the easy one to automate. Regex checks, type checks, range checks. So it's the one organization's measure. And it's the one that ends up labelled data quality in the dashboard.

SPEAKER_01 7:20

And meanwhile, the data is perfectly formatted nonsense.

SPEAKER_00 7:23

Polished on the surface, shaky underneath.

SPEAKER_01 7:26

Right, one more. Give me one with a number that'll make a CFO put their coffee down.

SPEAKER_00 7:32

Citigroup 2020. They were administrative agent on a Revlon loan. They meant to wire about $7.8 million of accrued interest. The loan processing system they used required three specific fields to be set to an internal account number to make sure they didn't accidentally pay down the principal. The person doing it set one of the three fields. The two reviewers checked it, and each of them assumed the one field was enough.

SPEAKER_01 8:00

Three fields, six eyes, one actually set.

SPEAKER_00 8:04

Citywide, $894 million. Revlon's entire outstanding principal balance to the penny. Three years before it was due. Out of City's own funds. And the amount they sent was 114 times the amount they meant to send. A range check, one of the simplest things you can write, comparing the outgoing wire to the expected interest schedule, would have stopped it cold.

SPEAKER_01 8:33

Okay, that one is genuinely uncomfortable. And it's interesting because it's not one dimension failing, is it? It's two or three at once.

SPEAKER_00 8:41

Yeah. Validity. The field configuration was wrong. Accuracy. The amount was off by two orders of magnitude. And integrity. The six eyes control existed on paper, but wasn't actually specified well enough to catch the failure mode. And none of those three were monitored together, so the gap between them was where the loss happened.

SPEAKER_01 9:05

Alright, I'm going to stop being skeptical out loud because I think the audience can hear the conversion happening in real time.

SPEAKER_00 9:12

You were a tough sell for about eight minutes.

SPEAKER_01 9:15

I do my best. But here's what's interesting to me, because we're a podcast about AI. None of those three stories I just heard had AI anywhere in them.

SPEAKER_00 9:24

No, they didn't. Those are old-fashioned, 20th and early 21st century failures. The reason we're talking about them is that AI doesn't replace any of these failure modes. It scales them.

SPEAKER_01 9:37

And this is the bit that ties back to last episode.

SPEAKER_00 9:40

This is exactly the bit. There's a piece of research from CHI 2021, Samba Sivan and colleagues. They interviewed 53 high-stakes AI practitioners, healthcare, finance, that kind of work. 92% of them had experienced what they called data cascades, upstream quality issues that manifest as failures months or years downstream, often after the model has already been deployed and people have started trusting it.

SPEAKER_01 10:12

92%.

SPEAKER_00 10:15

And IBM's 2025 Chief Data Officer Study landed in a very similar place. When they asked CDOs what's blocking them from getting value from AI, the answer was almost word for word the dimensions we just listed: accessibility, completeness, integrity, accuracy, consistency.

SPEAKER_01 10:37

The same dimensions, just being amplified at machine speed.

SPEAKER_00 10:41

And the IBM study had this line I keep coming back to. They said human analysts will work around incomplete or inconsistent data. They'll notice it. They'll caveate it. They'll go and ask someone. AI agents will perpetuate it and scale it.

SPEAKER_01 11:01

That's exactly the thing we called false confidence last episode. Bad advice delivered with executive presence. And it's even worse with an agentic system, because it's not just generating one wrong answer for a human to evaluate, it's taking actions or feeding the next agent in the chain or writing back into a system of record.

SPEAKER_00 11:23

And the human in the loop, if there is one, sees something that looks fine.

SPEAKER_01 11:27

Okay, can I share something? Because we were going to put one of these in here.

SPEAKER_00 11:31

Please.

SPEAKER_01 11:32

A site I'm familiar with. Heavy industrial, the kind of environment where data quality is not a back office concern, it's a safety concern. The inspection data wasn't always being recorded. The site boundaries weren't clearly defined in the system. Hazards and observations were being captured inconsistently across teams. And the failure mode wasn't a single catastrophic data error. There was no one moment you could point to and say, that's where it broke. It was systemic ambiguity. Different people were looking at the same incomplete picture and interpreting it differently. Decisions that should have been standardized became subjective. And the hazards were real. They existed on the ground. They just weren't clearly captured, communicated, or trusted in the data. This led to a safety incident involving a piece of heavy machinery.

SPEAKER_00 12:25

Hmm. And that's the thing that's hard to convey to people who haven't lived it. The data doesn't have to be catastrophically wrong to be catastrophically risky. It just has to be ambiguous enough that everyone fills in the gaps differently.

SPEAKER_01 12:41

That's the bit. There was no single error. The risk just built quietly. And it was going to depend on something else combining with it. A tired shift, an unfamiliar contractor, a piece of equipment in the wrong place, for the latent risk to actually become an incident.

SPEAKER_00 12:58

Yeah. And this is where the multi-dimensional view earns its keep. Because if you'd only been measuring accuracy, the inspections that did get recorded, were they correct, you would have reported good data quality. The records you had were fine. The problem was the records you didn't have. That's completeness. And consistency. The same thing meaning different things to different teams. And believability, the degree to which people on the ground actually trusted what the system was telling them, which they didn't.

SPEAKER_01 13:33

Which is why a single data quality score is so dangerous. It would have looked green.

SPEAKER_00 13:38

It would have looked green, while the conditions for an incident were sitting underneath it.

SPEAKER_01 13:43

And for an executive, this is the thing I want to land. It's not just safety. The same shape of failure shows up in your financial controls, your customer data, your risk reporting, your AI training sets. It's the same pattern. Incomplete, inconsistent, ambiguous data, and a polished number on top of it that everyone treats as true.

SPEAKER_00 14:06

Polished on the surface, shaky underneath. That one keeps earning its keep.

SPEAKER_01 14:11

It really does. Alright, you teased an Australian case earlier. Let's hand off to next episode with it because I think it deserves its own space.

SPEAKER_00 14:19

Yeah, so Robodebt. The Australian government's automated welfare compliance program. It cross-referenced fortnightly self-reported income from welfare recipients with annual income data from the tax office. The problem is that annual data isn't fortnightly data. So the algorithm just averaged the annual income across all the fortnights, which, for anyone with seasonal or casual work, students, hospitality workers, anyone whose income isn't even, produced fortnightly numbers that were just factually wrong.

SPEAKER_01 14:56

Just to be clear about what the system was doing, it was generating debt notices. It was telling people they owed the government money.

SPEAKER_00 15:04

It was. And the Royal Commission report in 2023 confirmed that approximately 470,000 of the 567,000 debts issued under that program were invalid. The total settlement was about 1.8 billion Australian dollars. The University of Wollongong analysis described the methodology as breaking both the laws of the land and the laws of mathematics. Wow. And every value the system used was valid. Every field passed its checks. The data was syntactically perfect. It just had no relationship to fortnightly reality. There's a question that would have prevented the entire thing, and we're going to spend most of next episode on it.

SPEAKER_01 15:51

Save it.

SPEAKER_00 15:52

Saving it.

SPEAKER_01 15:53

Alright, let's land part one. I'm going to try and summarise where I've ended up, because this has actually shifted how I'd answer the question I started with.

SPEAKER_00 16:02

Go on.

SPEAKER_01 16:03

So at the top of the episode, I said, surely it's just, is the number right? And what I've heard today is that's actually one question out of at least seven, and not even the most important one for most uses. Public Health England wasn't an accuracy problem, it was a completeness problem. Mars was a validity problem masquerading as one. Citigroup was a couple of dimensions failing in a gap nobody was watching. My safety example was a consistency and believability problem that never would have shown up as a single error. And Robodebt was a system that was perfectly valid and catastrophically not accurate.

SPEAKER_00 16:41

That's the whole thesis.

SPEAKER_01 16:43

So, as a leader, if you're about to approve an AI investment, the question is not, is the data accurate? The question is, which of these dimensions matter for what we're trying to do? Who owns each one? And how would we know if any of them quietly drifted? Because AI is going to scale whichever one you got wrong, and it'll do it in a tone of voice that sounds correct.

SPEAKER_00 17:06

That's the whole thesis in two sentences. I think we can stop now.

SPEAKER_01 17:10

But we shouldn't, because we haven't talked about what to actually do about it.

SPEAKER_00 17:14

Right, and that's next time. Because the answer isn't a three-year data quality program. There's a small set of high-leverage moves, and one specific question that, if it had been asked, would have prevented Robodebt entirely. That's where we're going next.

SPEAKER_01 17:30

Alright, Sarah, before we wrap, a confession. I've been sitting here for the last 20 minutes lecturing executives about fitness for purpose, and I have to ask. This podcast, the thing we are literally making right now. How does it score on the seven dimensions?

SPEAKER_00 17:48

Oh, you want me to audit us live, on air.

SPEAKER_01 17:51

Yep, I want you to audit us. Live, on air.

SPEAKER_00 17:54

Okay. Accuracy. Reasonable. I cited my sources. You can check the show notes. Completeness. We'll come back to that one because there's clearly a whole part two we haven't recorded yet. Consistency. I'd say so. Although you keep calling it data quality hope, and I keep calling it data quality program, so there's a minor reconciliation issue. Timeliness. IBM study is 2025. We're in good shape. Validity. The format conforms to a podcast. I think we're okay. Integrity. Every claim has a source behind it. And uniqueness. There is definitely only one of this podcast, James.

SPEAKER_01 18:41

Tragically.

SPEAKER_00 18:42

So six out of seven. Pending part two for completeness.

SPEAKER_01 18:46

Six out of seven. I'll take it. Although I notice you skipped believability.

SPEAKER_00 18:52

I skipped believability because that one's between us and the audience, and I didn't want to put them on the spot.

SPEAKER_01 18:59

Polished on the surface, shaky underneath.

SPEAKER_00 19:02

Don't you dare.

SPEAKER_01 19:03

Look, if a podcast about data quality can't even score itself honestly against its own framework, what hope does anyone else have? That's actually the perfect setup for next week, because in part two, we're going to talk about how serious organizations actually measure this stuff in production. Not vibes, not self-assessment on a podcast, real measurement.

SPEAKER_00 19:27

With real consequences when you get it wrong.

SPEAKER_01 19:30

Thanks for listening to AI Beyond the Hype. I'm James.

SPEAKER_00 19:33

And I'm Sarah. If you got value out of this, share it with someone on your leadership team, particularly someone making AI investment decisions in the next 90 days. Part two drops next week.

SPEAKER_01 19:45

And remember, better AI still starts with better foundations.

SPEAKER_00 19:49

Even when the foundation is a podcast.

SPEAKER_01 19:52

Especially then.