AI in Manufacturing and Supply Chain

Manufacturing has had machine learning in production for decades, and it works. The mistake available now is to point a language model at the problems that are already solved by something faster, cheaper and more precise, while leaving untouched the enormous pile of writing that nobody has ever been able to process.

Where the line actually falls

The boundary is not a matter of taste. Three physical requirements decide it, and where any of them binds, a language model is the wrong component.

• Sampling rate. Vibration analysis on a bearing samples at kilohertz. Predictive maintenance works on the frequency spectrum of that signal, where a developing fault appears as energy at a specific multiple of shaft speed. There is no text here and there is no token budget that would make there be.
• Decision latency. A vision system rejecting a part on a line running at several hundred parts per minute has single-digit milliseconds and a fixed physical position at which the ejector fires. That is a small convolutional model on an industrial PC beside the camera. A round trip to an API is three orders of magnitude too slow and, more decisively, is not allowed to be on the network at all.
• Numeric precision under structure. Demand forecasting is a hierarchical time-series problem — forecasts by SKU, by location, by product family, which have to reconcile so the parts sum to the whole. That reconciliation is a linear-algebra step with a literature behind it. A language model produces a plausible number and no guarantee that the family total equals the sum of its SKUs, which is the only property the planners need.

What is left after those three is everything written by a human, and in a manufacturing business that is far more than it looks.

The free-text field on every work order

Every CMMS in the world has a description field on the work order, and it is full of exactly this: "repl brg DE side, noisy, 3rd time this yr". Millions of them, written by technicians in a shorthand that is consistent within a plant and inconsistent between plants, containing the actual failure history of the asset base. The structured failure-code field beside it is either blank or set to whatever was first in the dropdown.

Normalising that text into a failure taxonomy — component, failure mode, cause, action taken — is a classification task that language models are genuinely good at, and it is valuable because of what sits downstream. Reliability engineering methods that plants already use need failure modes as their input, and they are currently fed by somebody reading work orders by hand for a fortnight before an annual review. The output feeds the classical models rather than replacing them.

Evaluate it on per-class recall, and specifically on the rare classes. A macro-averaged score looks fine while the model quietly folds every instance of a rare, expensive failure mode into the common one beside it, and the rare expensive mode is the entire reason anyone wanted the taxonomy. The technique is standard LLM classification with a per-plant abbreviation glossary in the prompt, and it needs an explicit unclear class so that the model has somewhere to put the ones a human could not decode either.

The supply chain runs on email

EDI handles the transactions — orders, advance ship notices, invoices — and it is structured, specified and parseable. Putting a model on it is a category error. But EDI has never carried the part of a supply chain that actually moves: the supplier emailing that a shipment will be four days late because a sub-tier vendor is short on a resin, the engineering change notice that obsoletes a component, the quality escape notification, the certificate of conformance attached as a photograph of a printed page.

The valuable task there is not summarising. It is extracting a structured event — affected part numbers, affected purchase orders, the new date, the reason class — and posting it into the planning system, where a delay on a part with two weeks of cover is uninteresting and a delay on a part with two days of cover is a line stoppage. The model is doing entity resolution against your own part master, which is hard for a general system and easy once you feed it the candidate list: retrieve plausible part numbers by fuzzy match first, then ask the model to choose among them and to be allowed to choose none. Free-form extraction of a part number will hallucinate a check digit; selection from a candidate set cannot.

The network decides the architecture

Plant networks are segmented, and the segmentation is not negotiable by a software team. Control-system equipment sits on an operational network that is firewalled from the business network and frequently has no route to the internet at all, for reasons that predate all of this and are about safety rather than data. Anything you build that needs to see production data will consume an export or a historian replica on the business side, on a delay.

Three consequences follow, and they are worth knowing before the design rather than after the security review:

• The language layer lives on the IT side and reads. Nothing it produces writes back to a controller. A recommendation is a work order for a person, not a setpoint.
• Data currency is whatever the export schedule is. A system whose value depends on second-fresh process data cannot be built this way, which is another reason the good use cases are the documentary ones.
• Where a model genuinely must run near the line, it runs on hardware at the line — see edge inference and running models locally for what is feasible on the kind of industrial PC that survives in a cabinet at 45 °C.

The other constraint that shapes everything is that production data is commercially sensitive in a specific way: yields, scrap rates, cycle times and supplier prices are the things a competitor most wants and the things a customer would use in a negotiation. That makes contractual data-use questions unusually pointed here, and what a provider does with your inputs is a procurement question rather than an engineering one.