Why Industrial AI Projects Stall at the Data Layer — Lessons From the Shop Floor

Most industrial AI pilots do not fail because the model was wrong. They fail because the data the model was promised does not exist in the form anyone assumed. This is a familiar pattern to anyone who has scoped a predictive-maintenance or quality-analytics project for a manufacturing client. The kickoff deck says the plant has been “capturing data for years.” The discovery phase reveals that what the plant actually has is a decade of PDF inspection sheets, a SCADA historian nobody has queried since installation, and a set of acceptance records where the only stored field is a final pass/fail value.

The model was never the hard part. The hard part was that the process producing the data was designed to satisfy an auditor, not to be analysed. It is worth looking closely at one narrow, unglamorous industrial operation to see what the difference looks like in practice — because the distinction between data that supports AI and data that merely exists is easier to see in a mechanical process than in an abstract one.

A Small Example With a Clear Signal

In oilfield and tubular manufacturing, threaded pipe connections are assembled under controlled torque. The operation is simple to describe: a pin is rotated into a box until the sealing surfaces meet and a specified torque is reached.

The traditional acceptance record is a single number — the final torque. It is easy to capture, easy to store, easy to sign off. It is also almost useless analytically, and the reason is instructive. The physical quality of that connection is determined not by the endpoint but by the shape of the torque curve as rotation proceeds. A correct assembly produces a recognisable profile: a low, smooth rise while the threads engage, then a sharp inflection as the sealing faces contact, then a controlled climb to the final value.

Several distinct failure modes produce distinct, identifiable deviations from that shape. Debris in the threads produces a sawtooth during engagement. Surface adhesion between the mating parts produces a continuously rising curve with no inflection at all. Geometric interference produces an inflection that arrives too early. And — the important one — a connection that never sealed can still reach the correct final torque, producing a curve with no inflection point but a perfectly acceptable endpoint value.

Store only the endpoint and all five of those cases collapse into one indistinguishable record: “passed.”

The Analytical Consequence

This is the shape of the problem that kills industrial AI projects, expressed in miniature.

A dataset of a hundred thousand final-torque values has almost no information content relative to its size. Every row is a single scalar recorded at the moment of maximum ambiguity. You cannot train a classifier to distinguish failure modes that were never separately represented. You cannot do meaningful anomaly detection when the anomalies were compressed out before storage. And you cannot validate a model against ground truth when the ground truth was a human signature on a sheet.

The same dataset captured as time-series traces — torque against rotation, sampled at reasonable resolution, one series per assembly — is a different proposition entirely. Now the failure modes are separable in the data. Now unsupervised methods have structure to find. Now a model’s output can be checked against a curve a domain expert can read.

The information was always there physically. It was discarded at the point of capture because the capture system was specified around a compliance requirement rather than an analytical one.

Three Questions Worth Asking During Discovery

For teams scoping AI work in industrial environments, this suggests a set of questions that are more predictive of project success than anything about model architecture.

What is the sampling resolution of the primary measurement, and is it fixed? A signal sampled coarsely, or at a rate that varies with machine speed, will have had its diagnostic features smoothed away before anyone sees it. This is recoverable only by changing the capture, which means new equipment or new firmware — a very different conversation from the one the client expected to have.

Is each record keyed to a physical object, or to a time window? Industrial data keyed to shifts, batches or dates cannot answer questions about individual components. If the client’s actual question is “why did this specific part fail,” and the data is keyed to “Tuesday’s production,” no model will bridge that gap. Object-level keys — serial numbers, heat numbers, joint identifiers — are the difference between a dataset that can support root-cause analysis and one that can only support reporting.

Can the data leave the machine? A surprising amount of industrial instrumentation displays rich information locally and exports almost none of it. An operator can see a live curve on a panel; the system stores a summary value. If the export path does not exist, the analytical dataset does not exist either, regardless of what the sensor is capable of measuring.

That third question is the one most often answered too optimistically during sales conversations and too late during implementation.

Where This Lands for Equipment Specification

The implication runs in an unexpected direction: decisions that determine whether industrial AI is possible are frequently made years earlier, by people procuring machinery, using selection criteria that contain nothing about data at all.

Capital equipment is typically compared on capacity, throughput, footprint, and price. A hydraulic assembly unit for tubular connections, for instance, gets compared on torque range and the pipe diameters it accommodates. Those are the numbers in the brochure and the numbers in the tender.

The data specification — whether rotation is captured alongside torque, at what resolution, whether the record is keyed to the component, and whether it exports in a machine-readable format — is rarely a scored criterion. Yet on a machine that will remain in service for a decade or more, it determines whether that decade of operation produces an analysable asset or a filing cabinet.

Equipment manufacturers have begun responding to this. Firms such as Galip Equipment, which build hydraulic bucking units for oilfield tubular and downhole tool work, now treat torque-turn monitoring and data export as specification points alongside the mechanical ratings — because buyers in tubular services increasingly need to produce evidence, not just a passing value, when a connection is questioned by a client.

The same logic applies to the disassembly side of the process. A breakout unit that records the torque required to release a connection is generating a genuinely useful signal: an assembly that took far more force to release than expected is telling you something about what happened during its assembly, potentially months earlier. That signal exists only if somebody decided to record it.

The Pattern Generalises

None of this is specific to threaded connections. The same structure appears across industrial domains:

Welding. Current, voltage and travel speed as time series characterise a weld. A pass/fail stamp does not. Porosity and lack-of-fusion have different signatures in the parameter trace and identical signatures in the stamp.

Injection moulding. The cavity pressure curve describes what happened during the shot. Cycle time and a dimensional check on a sample do not.

Rotating equipment. Vibration spectra distinguish bearing wear from misalignment from imbalance. An overall RMS value distinguishes none of them.

Heat treatment. The thermal profile through the cycle determines metallurgical outcome. A peak temperature reading is a summary of a summary.

In each case the industry has a well-understood physical signal, a well-understood set of failure modes with distinct signatures, and a widespread practice of storing a scalar summary that discards exactly the information needed to separate them.

The Labelling Problem Nobody Budgets For

Even when the raw signal has been captured properly, industrial datasets tend to arrive without usable labels, and this is where a second wave of projects quietly stops.

Supervised approaches need examples of the thing you are trying to detect. In a well-run plant, the thing you are trying to detect is rare by construction. A workshop with a two percent rejection rate will produce forty-nine good examples for every bad one, and the bad ones will be recorded with a free-text reason field filled in by whoever was on shift. “Galling,” “galled,” “thread damage,” “damaged” and a blank entry may all describe the same physical failure.

Three practical consequences follow.

Free-text reason codes need to become controlled vocabularies before they are worth anything. This is not a modelling task, it is a process change, and it needs to happen at the point of data entry. Retrospective normalisation of five years of free text is possible but lossy, and the loss is concentrated exactly in the ambiguous cases that matter most.

The second is that the physical artefact often outlives the record and can be re-examined. Unlike most software domains, industrial processes leave the evidence lying around. A rejected component sitting in a quarantine rack can be inspected today and its condition tied back to the trace recorded when it was assembled. Several of the most useful industrial datasets we have seen were built this way — not from historical records, but from a deliberate campaign of pairing retained physical parts with their stored signals.

The third is that the rejection decision itself is a label, and it is frequently wrong. A conservative inspector rejects marginal components; a busy one passes them. Model training against that decision teaches the model to reproduce the inspector, including the inconsistency. Where the physical artefact is still available, adjudicating a sample of disputed cases against a single expert produces a far cleaner target variable than the operational record does.

None of this is exotic data science. It is the unglamorous work that determines whether the interesting part is possible, and it is routinely absent from project plans because it does not look like AI work.

Scoping Honestly

Putting the pieces together suggests a different shape for an industrial AI engagement than the one clients usually expect. The first phase is an assessment of what the capture layer actually contains: resolution, keying, export path, label quality, and the retention window. It produces a written statement of which questions the current data can answer, which it could answer after a defined instrumentation change, and which it cannot answer at all. That document is more valuable than a proof of concept built on a convenience sample, because it prevents the expensive failure rather than deferring it.

The second phase, where required, is instrumentation and process change — and this is the point at which the client’s equipment procurement standards become part of the AI project, whether anyone planned for that or not.

Only then does modelling start, and by that point it is usually the least uncertain part of the work.

What to Do About It

For teams building AI systems in this space, three things follow.

Audit the capture layer before scoping the model. The productive first deliverable in many industrial AI engagements is not a proof of concept but a data-readiness assessment that states plainly which questions the existing data can and cannot answer. This is unglamorous and it prevents the failure mode where six months of work terminates in the discovery that the necessary signal was never recorded.

Treat the capture specification as part of the solution architecture. If the required data does not exist, the project’s first phase is instrumentation, not modelling. Framing that honestly at proposal stage is better than discovering it at integration.

Push the requirement upstream. The most useful long-term intervention is to get data specifications — resolution, keying, export format, retention — into equipment procurement criteria. This is a slow, organisational change and it is where the compounding value sits. Every machine bought without it commits an organisation to another decade of unanalysable operation.

The organisations getting genuine value from industrial AI are not, in general, the ones with the most sophisticated models. They are the ones that decided several years ago to record the curve instead of the number.