Your Data Can Change Which AI Project You Build First
Some AI ideas need a history you have not started collecting.
Years of maintenance records can describe every repair without giving you enough evidence to test an early warning system.
That is the sort of distinction I want to discover before putting a launch date next to an AI project.
Consider a fictional manufacturer with two ideas: help supervisors review yesterday’s maintenance work, or warn engineers before the next equipment failure. Both proposals point to the same maintenance archive. Both include a line for “data preparation.”
Then the team opens the records. There are accounts of completed repairs, parts replaced, and work carried out after breakdowns. The operating measurements needed for the proposed warning system are absent from this extract. Nobody has yet established whether they are stored elsewhere.
The summary has source material the team can examine and test against. The warning proposal has a question about its inputs that could change the scope, cost, and timing of the whole project.
The review may tell us to start recording something now, while we are still deciding which product to build.
What is inside “data preparation”?
For the warning proposal, the engineers need to work out what information would have been available early enough to support a useful alert. Depending on the approach, that could include earlier service history, error logs, or measurements from the equipment. Repair history can contribute; the archive’s size alone cannot establish whether it is enough.
A predictive-maintenance example published by Microsoft in 2019 combines failure and maintenance records with sensor readings and information about the machines. Those are separate ingredients. Finding one does not tell you whether you have the others.
Now suppose the team investigates. There are several ways that investigation could end.
The readings might exist in another system, under equipment identifiers that need reconciling. The next work is to obtain access, establish the links, and check the history. A proposal that looked like a modelling task now has a concrete integration dependency to estimate.
Or the required readings might never have been recorded. If this warning approach depends on them, the team has to consider collecting new observations or changing the approach. Either choice deserves its own estimate. Cleaning the repair archive will not recover measurements nobody captured.
Get Minchan Chung’s stories in your inbox
Join Medium for free to get updates from this writer.
Those are very different commitments to hide under the same line in a plan. One involves working with existing evidence. Another may involve setting up data collection, maintaining it, and waiting for enough relevant history to assess the idea.
The first thing to start may not be the first thing to ship
It is tempting to respond by building the summary first. We have the records; let’s get something out.
I would still want to know what problem that summary solves. If supervisors already review the logs quickly and trust the result, an AI version may add little. Its data being close at hand is a weak reason to give it priority.
The warning system might address a much more consequential problem. Even then, an earlier prediction is useful only if someone can act on it. How much notice would the engineers need? What would they do differently? Could an existing alarm or a simpler change to the maintenance process achieve the goal?
If those answers justify pursuing the warning idea, the immediate investment might be a limited effort to establish the necessary data collection. That could begin while the product team is still choosing the first AI release.
This is the sequencing decision that interests me. You could spend the next development cycle shipping an easy feature and only then discover that the more valuable idea needs a history you have not started collecting. Or you could investigate that dependency now and decide whether the collection is worth funding.
The data review has changed what should happen first, even though it has not chosen the final product.
Keep the plan open long enough to learn
This is why I would involve data preparation while the shortlist of AI ideas is still open. You need a business problem and a few plausible ways to address it. You can then inspect the relevant sources without committing to a full build or cleaning every dataset in the company.
For each proposal, I want three questions answered:
- What can we test with the records we already have?
- What must we obtain or connect before that test means anything?
- What would we need to begin recording, and what would it take to judge whether that effort is worthwhile?
Put those answers beside the expected business benefit and the existing alternatives. They may justify a small trial, an investment in collection, a narrower proposal, or dropping an idea altogether. They should also make it harder to mistake a readily available dataset for a compelling product opportunity.
In our fictional factory, the useful finding is that the two proposals ask the company to make different commitments. A launch schedule drawn before that finding needs to be revisited. The team may still choose the same project, but it will be choosing with a better account of the work involved.
That is what I want from early work on AI-ready data: findings that can change the order in which we spend time and money. If a promising product needs a history we are not recording, I want to know before we spend the next development cycle on something else.
I’m Minchan Chung, co-founder of CUBIG. I write about AI-ready data and what I’m learning while building the company. New essays every Tuesday and Thursday. Follow me on Medium to read the next one.
