Do you have to fix your data or automation first?

There is a moment in most AI or analytics kick-offs where somebody says "we should sort the data out first", and the room relaxes. It is a responsible sentence. It buys time and sounds like rigour. I have never once seen anyone lose an argument by saying it, and I said it for years, meaning it every time. If you own the strategy rather than the systems, that sentence arrives at you as a verdict, delivered by people who know more about the plumbing than you do.

What does "our data is not ready" actually mean?

It usually means three or four separate problems bundled into one sentence, and the bundling is what costs you the year. Some of it is ordinary mess. Duplicate records that stay duplicated because merging them needs a sign-off. A lead-source picklist that had grown to 41 options over six years, twelve of which were spelling variants of "webinar". And the easy part? This could all fixable in a fortnight by one person with a mandate.

The rest is harder. Leadership teams want 'one truth', based on definition, yet their "active customer" has multiple definitions depending on which team you ask from. Sales might count anyone with a deal. Finance counts everyone they invoiced in the last quarter. And then theres support, who counted anyone with a live entitlement. Each definition was correct inside the system that produced it, and each had been correct for years. The disagreement only surfaced the week somebody tried to build a single number on top of all three.

That is how a deduplication project becomes a governance project. You start by merging records. You finish in a room deciding what your company means by a customer, which was never on the project plan.

Ward Cunningham's original 1992 argument about technical debt mostly gets lost now the phrase is everywhere: borrowing is a reasonable way to move quickly, provided you know you are carrying the debt and you service it. The failure is not the borrowing. It is finding out the balance in the same week you need the answer. Data debt behaves the same way, and every company I have worked in was carrying some.

Why did I keep saying "we need the data sorted first", then?

Because it is true, and because it is safe. "The data is not ready" is close to unarguable, and it moves a deadline without anybody having to own the decision to move it, and this means you can get alignment between teams faster. Operations teams find that a comfortable place to stand, and I've stood there hoping that this is the month we actually get half decent reporting ready with definitions that are shared as a one business.

On one of those projects the data was in reasonable shape about eleven months in. By then the sponsor had left and the campaign it had been for was shelved. The person who inherited it opened a fresh audit, because he had not been in the room for the first one.

What changes if you do not wait?

Mostly, what changes is the order of operations. You take one question that matters and answer it properly against the systems as they stand today, while the estate-wide cleanup carries on at its own pace behind that.

That is the part of Unloq I would have wanted when I was doing this work. It connects to the systems you already run and resolves definitions consistently across every system a question touches, so the answer to "how many active customers do we have" does not change depending on where it was routed. Every answer carries its evidence trail, and a validation gate grades each figure pass, warn or block before it reaches anyone, and the model never invents a number. In most deployments none of your data leaves your environment while any of that happens.

The timescales are unremarkable, which I think is a point in their favour. The software installs in about two weeks. Onboarding to a first working deployment runs three to ten weeks depending on scope, and diagnostics you would be willing to take into a board meeting build over a quarter.

Where the cleanup crowd are still right

Bad data stays expensive: attribution goes wrong, and decisions get made on instinct because nobody trusts the report. None of that gets fixed by answering one question well; the underlying work still has to happen, funded and owned, on its own timeline.

And I cannot give you a rule for where the line sits. I have seen organisations where the mess was bad enough that starting anywhere at all would have produced confident nonsense, and I did not know they were in that category until we tried. Anyone who tells you they can spot it from the outside is selling you an audit.

The smallest useful test

Pick one question your leadership team cannot currently answer without three people exporting spreadsheets, and see whether it can be answered properly, with its working attached, against the data you have today. If it can, your data was ready enough. If it cannot, you will at least come out knowing which definition is broken, and that is a much shorter list than "fix the data".