Reef TRH"Garbage in, garbage out" is the most reassuring thing you can say about a failing AI project, because it points at a problem you think you can scrub away. Clean the data, the reasoning goes, and the model will behave. It is a comforting story, and it is mostly wrong. Believing it is how a quarter's budget quietly disappears.
Most enterprise data isn't dirty in the way that phrase implies. It is honest. It faithfully records fifteen years of a real business: the acquisition that left two customer tables that never quite reconciled, the product codes someone redefined in 2019, the one field that three departments each fill in differently because each was solving a different problem. None of that is an error waiting to be cleaned. It is the business, written down, and it is the exact terrain your model has to cross the moment it steps off the stage.
Why the demo lied to you
A prototype earns its applause on a set that was dressed for the occasion. The examples are chosen to be representative and unambiguous; the awkward records are quietly left in a drawer, because the point of a demo is to prove an idea is possible, not to survive contact with reality. What the room reads as the model's intelligence is, more often than anyone admits, the invisible labour of whoever groomed the data the night before.
Production keeps no such drawer. It hands the same model a live feed from systems that were never designed to speak to one another, and asks it to be right about the single messy record in front of it rather than the tidy average. The model did not get worse between the pitch and the pilot. Its diet did. That is the quiet mechanism behind the four in five pilots that never reach a real user: not a weak model, a starved one.
Which means the decisive work happens earlier than most teams expect, and it has nothing to do with choosing a model.
The reading you do before any model code
Before a line of training or integration code exists, you can already tell whether a project is buildable by interrogating the ground beneath it. Where does the data this use case depends on actually live, and who is the single person who understands each source well enough to explain its quirks? How complete is it on the specific fields the model must act on — not in aggregate, but record by record — and how stale is it by the time anyone reads it? Can a system reach it in real time through a real interface, or does the whole thing secretly rest on a manual export and someone remembering to run it on a Monday?
Then the questions that have nothing to do with data quality and everything to do with whether the answer gets used. Does the output land inside a real person's workflow, at the moment they make the decision it is meant to change, and does it respect the exceptions that process currently handles by hand? Once real records are in play, what is the model allowed to see, who may see what it produces, and what has to be logged so a decision can be defended a year later? These are not concerns to bolt on after launch. They are the design.
Answer them honestly and you will not end up with perfect data, because nobody has that. You will end up with something more useful: a map of precisely where the ground is soft, what it will cost to shore up, and whether the project is worth starting at all — while those answers are still cheap to hear. That is the entire job of a readiness assessment. It does not clean your data. It reads your data honestly enough to answer the question the demo never could: not whether the idea works, but whether it will survive your business.