The three questions that decide feasibility
Before any discussion of architecture, three questions determine whether a project is viable. They can usually be answered in a week.
- Is the outcome labelled? To predict scrap you need historical records of which units were scrapped, joined to the process conditions that produced them. Shift-summary scrap counts without unit-level linkage cannot train anything.
- Are timestamps synchronised? If the PLC historian, the vision system and the quality database disagree by even a few seconds, correlation across them is noise. Clock discipline is unglamorous and decisive.
- Does the data span the variation you care about? Twelve months of data from a process that only ran one product, one tool and one season will not generalise to the conditions you actually want it to handle.
The failure mode nobody plans for
The most common blocker is not missing data. It is a tag namespace that changed. Somebody renamed tags during a controller upgrade eighteen months ago, and the historian now contains two incompatible naming schemes with no mapping. Reconstructing that mapping is archaeology, and it is frequently the largest single line item in a first industrial AI project.
This is why we start every engagement with a data readiness assessment rather than a model proposal. It is a small, cheap piece of work, and it either de-risks the project or saves you the entire budget.
A readiness checklist
| Dimension | Minimum viable | Comfortable |
|---|---|---|
| History length | Covers 3+ cycles of the phenomenon | 12+ months across conditions |
| Sample rate | Faster than the dynamics of interest | 10× the dynamics of interest |
| Label quality | Unit-level outcome, consistently applied | Labelled with reviewer agreement measured |
| Time sync | All sources within 1 second | PTP or NTP disciplined, sub-100 ms |
| Join key | A unit or batch identifier that survives across systems | Full genealogy from raw material to shipment |
| Coverage | Includes failure cases, not only normal operation | Failure cases across multiple root causes |
Start narrow
The instinct to build a plant-wide data platform before proving anything is the single most reliable way to spend a large budget and show nothing after a year. One machine, one clearly defined outcome, one measurable baseline. Prove the value, then generalise the infrastructure to serve a use case that has already earned it.
Always measure against the incumbent
Every model must be compared to what it replaces: the experienced operator, the SPC rule, the fixed maintenance interval. Surprisingly often the incumbent wins, and finding that out in week six is a good outcome — it is the cheapest possible result. A team unwilling to run that comparison is not doing engineering.
Talk to us about this
If this is relevant to a line you are working on, our engineers are happy to look at the specifics. Related capability: AI for Manufacturing. You can also browse delivered projects, the technology stack or contact the engineering team.