Intelai
The Data Janitor Is the Domain Expert
Cleaning data is not janitorial work. Every fix encodes a judgment about what a row means, and that judgment belongs to the people who own the process.
The joke in "data janitor" is that the work is beneath the people who do it. That joke is expensive. The person who decides that a null means zero and a zero means missing is making an accounting decision, and if they get it wrong, the model learns the error and reports it with confidence.
Data cleaning is the AI project. Not a phase before it, not a chore handed to the newest analyst. It is where the organization's rules become code, and the quality of that translation sets the ceiling on everything downstream.
Every cleaning decision is a business rule
A dataset does not arrive with instructions. It arrives with history, and every artifact in it is a decision someone made.
Null versus zero. A missing quantity and a quantity of zero are different facts. A system that conflates them will understate demand or overstate inventory, depending on the direction of the error. The fix is not a fill strategy. It is a definition, owned by someone.
Duplicates. Two records for the same customer, the same part, or the same transaction. Which one is true? Often neither, and the correct answer is a merge with a documented rule. Fuzzy matching can propose the merge. It cannot decide which address is current.
Units. A unit of measure is part of the number. A file that mixes cases, eaches, pounds, and kilograms is not one dataset. It is several, stacked.
Time. Time zones, fiscal calendars, and effective dates. A record that says "March" could mean three different months depending on which calendar the source used. A join across two systems with different conventions produces a result that is wrong in a way that looks normal.
Status codes. Every legacy system has a status field with values that changed meaning over time. "Active" in 2019 is not "active" in 2025. The mapping is a historical claim, and it needs a source.
None of these are technical problems in the sense that a tool solves them. They are decisions about what the data means, and they have to be made by someone with the authority to be wrong.
The failure modes and the question that catches them
| Failure | What it looks like | The question that catches it |
|---|---|---|
| Null treated as zero | Averages drift down, totals look plausible | What does an empty cell mean in this source? |
| Duplicate entity | Counts inflated, one customer gets two histories | Who decides which record survives a merge? |
| Unit mismatch | A quantity off by a factor of a thousand | What unit is this column in, and where is that written? |
| Date ambiguity | Records land in the wrong period | Which calendar and time zone does the source use? |
| Status drift | Old records counted as current | When did this code change meaning, and who approved it? |
| Leakage | A model that scores well and fails in production | Was this field known at the time of the decision? |
The last one deserves its own paragraph. Leakage is when a feature contains information that would not have been available when the prediction had to be made. A cancellation date in a churn model. A final disposition in a claims model. The model looks excellent in testing and useless in production. The cause is not a modeling error. It is a failure to ask what the row looked like at the moment of decision.
Why the work cannot be fully outsourced
A vendor can clean a dataset. A vendor cannot know which of two conflicting records is true, because that fact lives in the organization, not in the file.
This is the reason data cleaning projects stall. The cleaning team produces a list of questions, the questions require a business owner, and the business owner is busy. The list grows. The project waits.
The teams that get through it do something unglamorous. They assign an owner to each contested field, put the owner's decision in a document, and encode the decision as a rule with a test. The rule is then a asset that survives the project, the vendor, and the model.
What good looks like
Four practices separate an organization that can feed a model from one that cannot.
A data contract at the boundary. Every interface that supplies data has a written definition of its fields, units, allowed values, and update cadence. A contract that is not written is a rumor.
Validation at entry, not at analysis. A bad value should be rejected where it is created, by the person who can fix it. A validation rule applied at the end of the pipeline is a complaint department.
One owner per field. Not a team. A person. The owner does not have to be senior. They have to be reachable and accountable.
A change log for meaning. Not just for values. When a status code changes meaning, the change is dated and recorded. Without it, the history is unusable after the first redefinition.
The unglamorous advantage
The organizations that get value from AI will not be the ones with the best models. Models are available to everyone, and the gap between them closes every quarter.
The durable advantage is knowing what your data means, being able to prove it, and being able to change the definition without rebuilding the pipeline. That is the work the joke dismisses. It is also the work that decides whether the model is a capability or a demo.