Intelai
"Clean Your Data First" Is Unbounded Advice
Data is never clean. It is either fit for a specific decision or it is not, and the difference is a threshold somebody wrote down before the build.
The most expensive sentence in enterprise AI is "we need to clean our data first."
It sounds responsible. It is unbounded. There is no data set in any organization that is clean in the abstract, so the project has no exit condition, no way to declare victory, and no way to be wrong. It can absorb a budget for three years and end with a nicer warehouse and the same unanswered question.
Clean is not a property of data. It is a relationship between data and a decision.
Tolerance, not cleanliness
Ask what the decision needs, and the standard becomes concrete.
A model that flags invoices for review can tolerate a misspelled vendor name, because the amount and the purchase order number carry the decision. It cannot tolerate a duplicate invoice number.
A readiness report can tolerate a missing maintenance note. It cannot tolerate two different hour-meter readings for the same aircraft on the same day.
A contract closeout check can tolerate an inconsistent date format. It cannot tolerate a modification that was never recorded.
Each of those is a threshold, and a threshold can be written down, tested, and argued about. "Clean" cannot. That is the entire advantage.
A data quality requirement without a threshold is a preference. A preference will lose to every schedule conversation it meets.
The checklist that never ends
The standard quality dimensions are accuracy, completeness, consistency, timeliness, validity, and uniqueness. They are a fine vocabulary and a terrible plan, because each one can be improved forever.
Completeness is the trap. There is always a field that is 94% populated, and the last six points cost more than the first ninety-four. Whether they are worth it depends entirely on whether the decision changes at 94 or at 99, and nobody can answer that without the decision written down.
The same is true of the cleaning itself. Normalizing addresses, deduplicating entities, reconciling units. Every one of those is real work with a real payoff, and every one of them can expand to fill the quarter. The discipline is to do the work that moves the decision and leave the rest visibly undone.
Leave it visibly undone, not silently. A known gap with a note is a managed risk. A gap nobody noticed is the thing that shows up in the audit.
Build the check, not the clean
A data quality check has four parts, and most programs build the first one and skip the rest.
The rule. One condition, expressed so a machine can evaluate it. "Invoice number is unique within a fiscal year." "Hour-meter reading is greater than or equal to the previous reading for that asset."
The threshold. How often the rule may fail before the pipeline stops. Zero for a duplicate payment risk. Some percentage for a formatting issue.
The owner. A person who gets the alert and can act. Not a team channel.
The consequence. What happens when the threshold is crossed. Ideally, the pipeline refuses to publish and the downstream consumer sees a stale-but-known number instead of a fresh-but-wrong one.
The fourth part is where programs fail, because refusing to publish is unpopular. A pipeline that publishes anyway, with a warning in a log nobody reads, has no consequence and therefore no control. It has a dashboard.
What day one looks like
Pick one decision the organization already makes on a schedule. The weekly maintenance prioritization. The monthly invoice review. The quarterly obligation report.
Write down the three conditions that would make that decision wrong. Not the twenty things that could be better. The three that would produce a bad call.
Implement those three as checks, with owners and consequences, before you touch the model or the warehouse. Run them against the data as it is today and publish the failure rate internally, including the embarrassing number.
That number is the most useful artifact you will produce all quarter. It converts an argument about cleanliness into an argument about a threshold, which is a conversation a program manager can actually win.
The order of operations
Do not clean the data. Make the data's fitness measurable, then improve the measurements that matter to a decision.
The difference in practice is that the second approach has a stopping point. You stop when the checks pass at the threshold the decision requires, and you stop with a documented list of what you chose not to fix. That list is a defensible position.
You will never have clean data. You can have data whose defects are known, measured, and owned. That is the standard a system has to meet before anyone should trust it with a decision, and it is reachable in weeks rather than years.