Data Problems Compound Before Model Problems Appear

AI demonstrations put the model at the center.

Real systems often fail somewhere earlier.

A source was incomplete. A label meant different things to different people. A proxy was used because the real condition was expensive to observe. A correction never made it back to the training or evaluation data.

These issues can travel downstream and become difficult to see by the time a model produces an answer.

Researchers have called this pattern a data cascade: a compounding sequence of negative effects triggered by data problems that conventional AI and machine learning practices undervalue.

The first error may look harmless

Imagine a construction organization wants to predict which project issues are likely to affect schedule performance.

The historical data comes from issue logs across several projects. One team closed an item when the responsible person responded. Another closed it only after the field condition was resolved. A third project rarely updated status at all.

The field is named “closed” in every dataset. It does not describe the same event.

If the records are combined without that context, the model may learn a pattern that reflects reporting behavior more than project performance.

The problem began with meaning and process. It appears later as a model problem.

Provenance helps people ask the right question

Data provenance records where information came from, how it changed, and who or what was responsible for each step.

That history can help a team inspect:

• who collected the data;
• which project condition it represented;
• what definition was used;
• how missing values were handled;
• which transformations were applied;
• whether the source or label changed over time.

Provenance does not make weak data strong. It makes the weakness easier to locate and discuss.

System-level metrics may arrive too late

A team may evaluate an AI system only after the model is trained by measuring accuracy or another aggregate performance metric.

That can hide local failures.

If the training data excludes a type of project, underrepresents a region, or uses a proxy that works differently across groups, one top-line score may not show who receives a poor result or why.

Data review should begin while the question, collection method, and labels can still change.

Domain experts belong in the data work

The Google Research study that introduced data cascades drew on interviews with 53 practitioners working in high-stakes domains. The authors reported data cascades in 92 percent of the cases they analyzed and described them as pervasive, often invisible, delayed, and often avoidable.

One response is to treat domain expertise as part of data design, not as a final review after model development.

For construction, the people who understand how a status, quantity, delay code, or field observation is created need to help define the data. They can explain where the record is reliable, where it is shaped by incentives, and where the same label hides different operating conditions.

Review one field end to end

A practical data-centric exercise is to choose one field that an AI workflow will rely on.

Trace:

1. the real-world condition it is meant to represent;
2. who records it and when;
3. the choices and incentives in that process;
4. how missing or disputed values are handled;
5. every transformation before the model sees it;
6. the groups or situations where the meaning changes;
7. the person who reviews the field when the system fails.

This review may reveal that the right improvement is not a new model. It may be a clearer definition, a better handoff, or a more honest statement of what the data cannot support.

Model quality matters. The chain of decisions that creates the data often matters first.

Research basis

Data Cascades in High-Stakes AI

Editorial disclosure: This adaptation and its representative image were developed with AI-assisted editorial and visual production, then reviewed and approved by Marcus Turner.