One Small Data Error Can Distort the Whole System

Imagine ordering one cup of coffee for 120 baht.

But when the order is recorded, the system turns it into 10 cups costing 1,200 baht.

For one row, that may look like a small mistake that is easy to fix.

But what if the data does not stop at the counter?

It may flow into accounting, the daily sales calculation, a manager's dashboard, next month's sales forecast, or even a dataset used to train a Machine Learning model.

The mistake does not necessarily end where it happened.

It can keep moving.

Until it becomes an answer that looks correct even though it started with wrong data.

That is why something as ordinary-sounding as Data Quality matters more than it first appears.

Before we talk about AI, can we trust the data it is given?

We spend a lot of time talking about how capable AI has become. New models answer questions better, analyze more data, generate more realistic images, and help with decisions across more kinds of work.

There is another question that gets less attention:

What happens when the AI is capable but the data was wrong from the start?

The short answer is simple:

AI can still produce a wrong answer with confidence.

This is not only an AI problem. Dashboards have it. Machine-learning systems have it. Recommendation systems have it. So does an ordinary Excel report.

They all have one thing in common:

They must trust some data before they can calculate an answer.

Where does one row of data go?

When we see a polished dashboard or a sales chart, we are looking at the end of the journey. A single number may have passed through more systems than we realize.

For an online store, the path might look like this:

Customer places an order
      ↓
Application / API
      ↓
Operational Database
      ↓
Data Pipeline
      ↓
Clean / Transform
      ↓
Data Warehouse
      ↓
Dashboard / ML / AI
      ↓
Business decision

Suppose a customer buys one product for 500 baht. The data might begin like this:

order_id: 10125
quantity: 1
price: 500
status: completed

But many things can happen on the way. quantity can become 10. price can become -500. The same order_id can be loaded twice. Or an order can be marked completed even though the customer cancelled it.

If those rows enter the warehouse without a check, the dashboard can be wrong in a perfectly functional way.

The chart still looks good. The system still runs. No red error appears.

That is what makes Data Quality problems dangerous:

A lot of bad data does not break the system. It lets the system continue with the wrong answer.

What does Data Quality mean?

Data Quality sounds simple: the quality of the data. In practice, “good data” means more than having no blanks or typos.

We usually look at several dimensions. It is easier to understand them through ordinary situations first.

1. Is the data complete?

Suppose we have a customer record:

customer_id: 152
name: Somchai
email:
country: Thailand

The email is missing. Is that wrong? It depends on what the data is for.

If email is optional, perhaps not. If the system must send a receipt by email for every order, the missing field becomes important.

This idea is commonly called Completeness.

2. Is the data valid and accurate?

Consider this:

age: 240

The field is not empty. The database accepts it. The system may not throw an error. But it is clearly strange.

Or:

temperature_celsius: -800

It is a real number, but not a plausible value in that context. This is where Validity and Accuracy matter.

A value can have the right format without making sense.

3. Is the data duplicated?

Suppose the order table contains:

ORDER-001 | 500 baht
ORDER-002 | 900 baht
ORDER-002 | 900 baht

Expected sales of 1,400 baht may become 2,300 baht simply because one row was loaded twice.

This happens often in data pipelines, especially when a failed transfer is retried. Retries are useful because they prevent data loss. But without a good duplicate strategy, preventing missing data can create duplicate data instead.

The related idea is Uniqueness. A duplicate is not automatically an error, though. History tables may intentionally keep multiple records for the same entity.

4. Do systems agree with one another?

The CRM says Customer 1001 = Active. Billing says Customer 1001 = Cancelled. Marketing says Customer 1001 = Trial.

Each system may have its own reason. But before we build a dashboard asking, “How many active customers do we have?”, we need to answer one question:

Which system is the source of truth?

This is about Consistency. It is not solved by writing better SQL alone; it also depends on the business definition.

5. Is the data fresh enough?

A dashboard can calculate every number correctly and still be unhelpful if its latest data is six hours old while users think it is real-time.

That is Freshness.

Imagine an inventory dashboard showing 10 items remaining. The last update was at 9 a.m. It is now 4 p.m., and nine items have been sold.

The number 10 is not “wrong” in the database. It is too old for the decision being made now.

Data Quality is therefore not only a Correct-versus-Incorrect question. Context changes what “good enough” means.

Garbage In, Garbage Out

Computer science has used the phrase Garbage In, Garbage Out for a long time. A downstream system cannot create truth from low-quality input by itself.

Suppose a company wants to forecast next month's sales:

January   = 1,000,000
February  = 1,100,000
March     = 12,000,000
April     = 1,050,000

If March really was high because of a major promotion, the data may be right. But if March should have been 1,200,000 and someone added one zero by mistake, a model without context may try to learn from it.

It does not know to say, “That was probably a typo.” It sees a pattern. Without a check upstream, one extra zero can change the forecast.

How does Data Quality relate to AI?

AI lets us produce answers from huge amounts of data much faster. It does not make the source data correct automatically.

Imagine an internal AI assistant. An employee asks, “How many units of Product A are left?” The assistant queries the database and replies, “There are 230 units left.”

That sounds useful. But what if the inventory table has not synced for two days? The problem is not necessarily the language model.

The model may have done every step correctly. It found the right table, called the right tool, read the database correctly, and summarized the result correctly. The final answer can still be wrong because:

Correct AI
+
Wrong data
=
Wrong answer

Building a real AI system is therefore not only about choosing the most capable model. We also need to understand the data pipeline behind it.

What does a Data Engineer do about this?

It is fair to say that a Data Engineer moves data from one place to another. In a real system, another important part of the job is making the data trustworthy as it travels.

Instead of sending every row directly into the warehouse, a system can add a checkpoint:

Source
  ↓
Raw Data
  ↓
Quality Checks
  ↓
Clean Data
  ↓
Warehouse
  ↓
Dashboard / ML / AI

A check might ask whether quantity > 0, whether price >= 0, whether order_id is unique, whether customer_id exists, or whether the data is less than 30 minutes old.

Rows that pass continue. Rows that fail can be separated for review:

                     ┌──→ Valid Data → Warehouse
Raw Data → Validation
                     └──→ Invalid Data → Quarantine

This is like checking baggage before a flight. We try to stop an abnormality before it enters the main system instead of discovering it after the damage has spread.

Why not just delete the bad data?

Suppose we find quantity = -15. It looks wrong. Why not delete it?

Because an unusual value can carry meaning. It might represent a return, a stock adjustment, a source-system bug, or an accounting transaction.

If the pipeline turns every negative value into zero, it may not be fixing the data. It may be deleting the meaning behind the data.

A good data system asks more than “Is this row right or wrong?” It also asks, “Why does it look wrong, and how should we handle it?”

Data Quality is not only a technical problem

Consider the phrase Active Customer.

Marketing might define it as a customer who logged in within 30 days. Finance might mean a customer with a paid subscription. Product might mean someone who used a core feature at least once in 14 days.

All three definitions can be reasonable. But if someone asks, “How many active customers do we have?”, the SQL can be correct and the database can be clean while the question still has no single answer.

The problem is the meaning of the data. That is why Data Quality connects to Data Governance: who defines what a field means, how it should be used, and which source is trusted for which question.

A beautiful dashboard does not prove good data

Modern dashboards make numbers look trustworthy. The charts are polished, the numbers animate, percentages move up and down, and the KPIs use familiar green and red signals.

But the appearance says nothing about the quality behind the dashboard. Revenue +12.4% may be calculated perfectly from the warehouse. If an order was duplicated on the way in, the dashboard can present a wrong answer beautifully.

When we look at an important metric, “What is the number?” is only half the question. We should also ask, “Where did it come from?”

Data Lineage: can we trace a wrong number back?

Imagine a CEO opening the dashboard and seeing that today's sales are 300% above normal. The first question is, “What happened?”

Without data lineage, a team may have to inspect every system one by one. With a recorded path, the route may look like this:

Dashboard Revenue
      ↓
fact_orders
      ↓
silver_orders
      ↓
raw_orders
      ↓
production database

We can work backward and find where the anomaly began. Data Lineage is like a tracking number for data. It tells us not only that the data arrived, but also where it came from and what happened to it along the way.

Data monitoring matters as much as server monitoring

Software teams monitor CPU, memory, latency, and error rate. A data platform should monitor the data too.

Suppose today's order count drops by 80%. The service is up. CPU, database, and API metrics look normal. The pipeline run is marked successful. Yet half the data may be missing.

So:

Pipeline Status = SUCCESS

does not mean:

Data = Correct

A pipeline can complete every technical step while the business result is still wrong.

How do we know when data is good enough?

There is no single perfect level of Data Quality for every system. The right level depends on the consequences of being wrong.

If a movie recommendation is off by one title, the impact may be small. For fraud detection, financial systems, medical systems, factory inventory, or safety systems, a small error can cost much more.

The better question is not “Is this data 100% correct?” It is “Is this data trustworthy enough for this kind of decision?”

From Data Quality to Data Trust

What an organization ultimately needs may not be the most data. It needs data that people are willing to use for decisions.

If every dashboard review includes “Can we trust this number?”, “Did the pipeline fail again?”, or “Why does Finance disagree with the dashboard?”, what disappears is not only data quality. It is trust in the data.

When people stop trusting a dashboard, they start making their own spreadsheets:

dashboard_final.xlsx
dashboard_final_v2.xlsx
dashboard_final_revised.xlsx
dashboard_final_REAL.xlsx

The goal is not to make every row perfect. It is to make the source, checks, and limitations visible enough that people can decide when to trust the result. That is Data Trust.

Can AI help fix Data Quality?

It can help with parts of the work. AI can detect anomalies, suggest schema mappings, find duplicates, analyze missing data, draft validation rules, and explain where a pipeline looks unusual.

But AI cannot fully decide the business meaning for us.

It may see quantity = -5 as suspicious. It may not know whether this company uses negative quantities for returns or treats them as errors.

The future of Data Engineering is therefore not necessarily “AI replaces Data Engineers.” It may be “AI helps Data Engineers inspect more complex systems faster.” Deciding what data should be trusted and what it means still requires engineering judgment and domain understanding.

What building a data platform has taught me

When we build a data project, it is easy to get excited about the visible end: dashboards, Machine Learning, AI, visualizations, or real-time analytics.

The work that takes time is often more ordinary:

• Is the data duplicated?
• Did the schema change?
• Is this Null acceptable?
• Is the data fresh enough?
• What happens when a pipeline run is retried?
• What should happen when the source sends a bad row?
• Where do we look when a transformation breaks?

These questions are less flashy than choosing an AI model. Once a system has real users, they can become some of the most important questions in the whole project.

One small data error may not stay small

Back to the first cup of coffee. One cup becomes ten. At first, it is one record. If nobody checks it, the path may become:

Wrong Order
   ↓
Wrong Revenue
   ↓
Wrong Dashboard
   ↓
Wrong Forecast
   ↓
Wrong Decision

Data-system errors behave a little like dominoes. The first piece may be small, but the effect depends on how many systems use that data next.

Source-data quality matters even more when the data is used to help Machine Learning and AI make decisions.

Before trusting an answer, ask where the data came from

When we see a dashboard, an AI answer, or a prediction, a few simple questions are worth asking:

• Where did the data come from?
• When was it last updated?
• Who defined this metric?
• Would the system detect a bad row?
• What happens after detection?
• Can we trace the result back to its source?

We do not have to be Data Engineers to ask them. Data Quality concerns everyone who uses data to make a decision.

Before asking how capable the AI answer is, we may need to ask how trustworthy the data behind it is.

Takeaway

1. A successful system run does not prove correct data

A pipeline can pass every technical step while sending bad data downstream.

2. Data Quality is more than Nulls and duplicates

It includes correctness, completeness, consistency, freshness, and business meaning.

3. Dashboards and AI cannot always repair bad source data

A convincing answer can still be built from data that should not be trusted.

4. Quality checks should happen before the data is used

The earlier a problem is found, the lower the cost of fixing it tends to be.

5. The end goal is not perfect data; it is Data Trust

People should know where the data came from, understand its limits, and know when it is safe enough to use.

Read on

If you want to see these ideas in a real data-platform workflow, I have a RetailGuard Data Platform project that takes data from Raw Data through Validation and a Quality Gate to the Warehouse and Reporting, with problematic rows stopped before they reach the report.