AI in manufacturing

Six things AI is good at
on a factory floor.

And the places it should not be allowed near. This is a guide rather than a pitch: what each application consumes, what it produces, and where it fails. We build two platforms for manufacturing, and they appear once, at the end.

The six applications Where it must not go

Why now

The interesting change was not the AI models.

Machine learning has been used in manufacturing for decades, under other names: statistical process control is a model, and so is a regression on tool wear. Three things changed at once, and none of them is the thing that gets written about.

  • The sensors were already there

    A modern controller, a coordinate measuring machine and a torque tool all emit data continuously. For most factories the constraint was never collection, it was that the data landed in five systems that could not be joined.

  • Models read unstructured things

    The majority of what a factory knows lives in drawings, specifications, certificates and email. Being able to read those reliably enough to extract structure is the change that opened up the paperwork half of manufacturing.

  • Inference moved to the edge

    A vision model can now run beside the machine rather than in a datacentre, which matters when the answer is needed inside a cycle time and when the network is the least reliable thing on the floor.

The applications

Six uses, and what each one actually needs.

Ordered roughly by maturity. Every entry names its inputs, because a technique you do not have the data for is not available to you, whatever the demonstration showed. Every entry ends on its limit, because a use case with no stated limit is an advertisement.

CANDIDATE a candidate, not a verdict. A person decides

01

Inspection by camera

Finding the defect a tired eye misses at the end of a shift.

A camera and a trained model look at every part rather than a sample, and flag the ones that differ from what a good part looks like. It is the most mature application on this list, because surface defects, missing features and misplaced labels are visual by nature and a factory already has the fixtures and the lighting.

Input
Images of known-good and known-bad parts, consistently lit
Output
A flagged part and the region that caused the flag
Limit
It finds candidates, it does not disposition them. A model trained on last year’s defects will not recognise a failure mode that has never happened before, which is exactly the failure mode that matters most.
ALARM BAND measured projected vibration, temperature, current draw the window to act

02

Predictive maintenance

Replacing the spindle bearing on a Tuesday instead of at 2am.

Vibration, temperature, current draw and acoustic signatures drift in patterns that precede a failure. A model watching those signals continuously can say that an asset is leaving its normal envelope, which converts an unplanned stop into a planned one and lets the part be ordered before it is urgent.

Input
Continuous sensor history, plus the maintenance record that says what actually failed
Output
A change in condition, and the window in which to act on it
Limit
It needs failures to learn from. On a well maintained asset that has never broken there is nothing to train against, and the honest first step is condition monitoring with thresholds rather than prediction.
6X ⌀ 6.60 NO. CHARACTERISTIC TOL 1 2 3 4 5

03

Reading documents and drawings

Turning a drawing, a specification and a customer flow-down into rows.

Most of what a factory knows is unstructured: PDFs, scanned drawings, standards, purchase-order clauses, emails from a customer’s quality department. Models that read text and geometry can lift the requirements out of those documents into structured records that the rest of the business can query, which is the difference between owning a document and owning its contents.

Input
The drawing package and the specifications it references
Output
Structured, numbered characteristics with their tolerances and sources
Limit
Extraction is not approval. Every extracted requirement has to be reviewable against the page it came from, and a person has to sign it before it governs anything.
AS PLANNED M1 M2 M3 idle AS SEQUENCED M1 M2 M3

04

Sequencing and scheduling

Deciding what runs next when everything is late.

Scheduling a job shop is a genuinely hard combinatorial problem: due dates, setup times, tooling, operator certification and machine capability all constrain each other. Optimisation and learned models can search that space far faster than a planner with a whiteboard, and can re-search it the moment a machine goes down.

Input
Routings, setup times, capability and certification constraints, live machine state
Output
A proposed sequence, and what it costs against the alternative
Limit
A schedule is only as good as the data underneath it. If setup times are guesses and the routing has not been updated in two years, a faster optimiser produces a wrong answer sooner.
the cell the model reconciled against reality, or it is fiction

05

Simulation and digital twins

Testing the change on the model before committing the cell.

A simulation of a cell, a line or a process lets a change be tried without stopping production: a new layout, a different buffer size, a heavier product mix. Paired with live data it becomes a twin, a model that tracks the real thing closely enough to answer questions about it.

Input
A model of the process, and live data to keep it aligned
Output
The consequence of a change, before the change
Limit
A twin nobody reconciles against reality drifts into fiction within months. The maintenance of the model is the project, not the building of it.
EVENT LOG Why did lot 4471 stop? Gauge G-114 left calibration at 09:40. source: log 3312 no source, no answer

06

Assistants over plant data

Asking a question in words instead of writing a query.

Language models sit well on top of an event log, a quality record or a maintenance history, and let a supervisor ask why an order is late without knowing which table to join. The useful version answers from the record and shows which record, so the answer can be checked rather than trusted.

Input
A queryable record with a stable structure and access control
Output
An answer, and a citation to the evidence behind it
Limit
An assistant that cannot show its source is a rumour with a good interface. It should read and explain, and it should not be the thing that writes, releases or signs.

The boundary

Where it helps, and where it must not go.

The two columns carry the same weight on purpose. Deciding which side a problem falls on is most of the work, and getting it wrong in a regulated process is expensive in a way that a failed pilot is not.

Suited to it

  • Problems where a good answer is recognisable but hard to specify, such as what a defect looks like.
  • High volume repetition where fatigue degrades a person, and where every item can be examined rather than a sample.
  • Search over a space too large to enumerate, such as sequencing a job shop under twenty constraints at once.
  • Reading unstructured input at a volume nobody would staff, such as a decade of drawings and their revisions.
  • Noticing that a pattern has changed before the change becomes a failure.

Not suited to it

  • Anything that must be exactly right every time and can be expressed as a rule. Write the rule; a rule can be audited and a model cannot be cross-examined.
  • Situations with no history to learn from, which includes the first article, the new alloy and the failure mode that has never occurred.
  • Decisions that carry legal or contractual weight: releasing a part, signing a record, dispositioning a non-conformance.
  • Anywhere the input data is unreliable. A model trained on a routing nobody has updated learns the routing nobody has updated.
  • Explanations after the fact. If the system cannot show the record behind an answer, the answer cannot be used in a regulated process.

Before you buy

Six questions worth asking any vendor.

Including us. Most of these are answerable in a sentence by anyone who has built the thing, and are answered with a case study by anyone who has not.

  1. 01

    What exactly does it consume?

    Ask for the input list before the demonstration. Most pilots fail because the data the model needs is not being collected, is collected inconsistently across shifts, or lives in a system nobody will grant access to.

  2. 02

    What does a wrong answer cost?

    A false flag on an inspection line costs a second look. A false negative on a flight-critical characteristic costs a great deal more. The tolerance for error should be set by the consequence, not by the vendor’s benchmark.

  3. 03

    Can it show its evidence?

    For anything touching quality, an answer without a traceable source is not usable. Ask what the system stores, for how long, and whether an auditor could follow a decision back to the data behind it.

  4. 04

    Who signs?

    Establish early which actions a person must take. In a regulated process, releasing, dispositioning and signing belong to a named, certified human, and any system that blurs that is creating a compliance problem rather than solving one.

  5. 05

    What happens when it is unavailable?

    If the model is down, does production stop? A system that advises can fail quietly. A system that gates has to be engineered for the day it is not there.

  6. 06

    Where does the data go?

    Drawings and process data are frequently export-controlled or covered by customer confidentiality. Establish where inference runs, what is retained, whether anything is used for training, and under whose jurisdiction it sits.

Where we fit

We build two of these. Three more run on records we already keep.

Everything above is true whoever you buy from. This is the part where we say what we do, once. Two of the six are ours to build. Three more depend on records the MES already holds: the inspection result and the release it gates, the machine telemetry on the bus, and the routing and setup times a schedule is only ever as good as. Simulation is outside what we do.

Spectra

The third application on this page. Spectra reads drawings, specifications and customer flow-downs, balloons the drawing and produces numbered characteristics with their tolerances, exported in the format the customer asked for. The model proposes; an engineer reviews every characteristic against the page it came from and signs before it governs anything.

How Spectra works

MES

The sixth, inside a system that governs the other five. The MES runs live operations, quality and the as-built record, and carries an assistant that reads the event log and explains what it finds. It advises and cites. It never performs a governed write, never releases a certificate and never signs, because those belong to a named, certified person.

How the MES works

Talk to us

Bring the use case you are unsure about.

The most useful first conversation is usually about whether a problem is an AI model problem at all. Plenty of them are a data problem wearing a model’s clothes, and saying so early is cheaper than a pilot that proves it.

Talk to us Explore Spectra