Clean the data first

Turning on AI in an operation usually starts with the same instinct: clean the data first. It sounds like due diligence, the responsible thing to do before pointing a model or a pipeline at anything that matters. So a cleanup project gets chartered. Someone owns it. A spreadsheet of inconsistent fields, missing values, and mismatched formats starts to fill up, and the plan is to work through it methodically before the real project begins.

The instinct is not wrong, exactly. Bad data does produce bad outputs, and nobody wants to be the team that shipped a model on garbage. But the cleanup gets scoped against an imagined future need rather than a specific present one, and that framing is where the trouble starts.

The problem shows up a few weeks in. Scope keeps growing. Every review surfaces one more inconsistent field, one more edge case, one more table that technically feeds into the system somewhere downstream. Each addition seems reasonable on its own, because "clean" for a use nobody has defined yet has no natural boundary. There is always more data that could be cleaner.

This is why cleanup projects chronically run long and rarely get declared finished. Cleaning in advance of use is cleaning against a moving target: the target keeps moving because it was never actually fixed to anything. The team is optimizing for a hypothetical rather than a decision, and hypotheticals do not have edges. Adding another data steward or another sprint does not fix this, because the scope problem is structural, not a matter of throughput.

The fix was not more discipline about the cleanup. It was changing what the cleanup was in service of. Instead of cleaning everything that might someday matter, we picked the one decision the data actually had to support right now, and worked backward from it: which fields does this decision touch, which records feed those fields, and where does the current mess actually break the specific thing someone needs to do.

That single question did the scoping work that the original open-ended charter never could. Fields the decision never touched stopped being anyone's problem, at least for now. The boundary was not decided in a meeting; it appeared on its own once the destination was concrete. Cleaning in the path of use turns an unbounded quality problem into a bounded, checkable one, because "clean enough for this decision" is answerable in a way that "clean" alone never is.

The narrowed cleanup finished in about a week, something the open-ended version had not done in months. The project it was blocking moved forward on schedule, without waiting on a finish line that was never going to arrive on its own terms. The rest of the data, the parts the decision never touched, is still messy, and that is fine: it was never in the way of anything specific, so cleaning it first was never actually necessary. The lesson generalizes past data. Anything scoped against "eventually we'll need this to be right" instead of "this decision needs it right now" tends to run long for the same structural reason.