Deciding what to apply machine learning to

The potential applications for machine learning (ML) and artificial intelligence (AI) appear limitless, making it challenging to determine where to begin amidst all the hype surrounding these technologies. And the challenge is real; defining the problem to solve is where all ML journeys begin. This blog will outline some key principles for identifying the types of problems ML can solve. It will also provide questions to help evaluate our options, an example of effective strategies as well as pitfalls to avoid, and guidance on how to define an ML project.

An evaluation of ML opportunities

About 70% of the value in ML comes from the problem definition, the available data, and the choice of operating point. 30% sits on the modelling.

Before defining an ML problem, it's helpful to understand the types of problems it can address.

Types of problems for ML

Almost every industrial ML application replaces one of three things:

A measurement — we have something cheap and fast, and we want something expensive and slow. Predict the slow thing from the fast thing. This is called a soft sensor or inferential measurement.

A judgement — a human currently looks at something and makes a call. Classification and detection.

A search — someone is hunting through a space of options by trial and error. Surrogate models and optimisation.

A machine learning problem can be seen as any A-to-B problem where human decision-making, experience, judgement, or analysis is required. These are the most common types, with some examples.

Regression predicts a numerical quantity.

Examples:

• Density
• Tensile or compressive strength
• Drying time
• Thermal conductivity
• Energy consumption
• Scrap percentage

Typical output: Predicted density = 147 kg/m³

Classification predicts a category.

Examples:

• Pass or fail
• Accept, rework or reject
• Surface defect type
• Likely cause of a non-conformance
• Machine operating state

Typical output: Predicted class = Hold for review

Anomaly detection identifies observations that differ from normal operating behaviour.

Examples:

• Unusual motor vibration
• Abnormal machine sound
• A previously unseen surface defect
• Sensor readings outside the normal process pattern
• Unexpected formulation behaviour

Typical output: Anomaly score = 0.87; inspection recommended

Computer vision interprets images or video.

Examples:

• Detecting cracks or voids
• Measuring edge damage
• Identifying discoloration
• Checking fibre distribution
• Confirming component presence
• Reading gauges

Natural-language processing, or NLP, works with text.

Examples:

• Categorising non-conformance reports
• Searching SOPs
• Extracting causes from maintenance notes
• Summarising test reports
• Identifying recurring complaints
• Drafting structured investigation reports

Optimisation searches for process or formulation settings that are likely to produce the best result.

Examples:

• Maximising strength while minimising density
• Reducing drying energy while maintaining quality
• Balancing thermal performance, cost and fire resistance
• Selecting process settings within safe operating limits

Optimisation generally comes after a sufficiently reliable predictive model has been developed.

With an understanding of what machine learning can achieve in manufacturing, we can begin to define our first machine learning opportunity map.

ML Opportunity Map - Choosing a problem to solve

Begin by creating a list of no more than five simple problems to solve. Then, rate them on a scale from 1 to 5 according to these criteria.

Once we have ranked the options, we can define the most viable problem to address. We can find an example and template of an AI Opportunity Charter here. It’s important to start small, as many projects fail because they attempt to cover too much at once. Assuming that the AI development project has proper sponsorship, an example of this decision-making process will help clarify the approach outlined so far.

A simple example

Based on the types of problems for ML, we can list ML use cases from my world.

Making all four criteria run 1–5 in the same direction is the right instinct. But averaging cost us something important, and it's worth seeing rather than taking on faith.

An average treats criteria as substitutable; it assumes a high score on one can compensate for a low score on another. For value and economic viability, that's fair. For data accessibility, it's false. If the data doesn't exist, the project cannot start. No amount of value compensates for that; it's a gate, not a dial.

Watch what happens to the ranking when the criteria multiply instead of average (using Value × Data × Feasibility, just to isolate the effect):

Two things fall out. The CV defect filter drops from mid-table to near the bottom — because averaging let a Data score of 1 hide behind a Value score of 5, and multiplication won't allow it. And the three-way tie at 3.75 resolves into a clear order.

That second point matters more than it looks: eight of the ten items are tied. A prioritisation tool that can't discriminate between eight options isn't prioritising. That's what a coarse 1–5 scale does when we average only four criteria, collisions everywhere.

The suggested fix is small. Keep the four criteria and the averaging, but add a gate step before scoring: any item with Data accessibility ≤ 2 goes to a separate "not startable this quarter" list. Then rank the rest. This gives discrimination without abandoning a method people will actually use.

The column that's missing

There's no n on the sheet. How many historical rows exist for each of these?

That single number is more decisive than any of the other four criteria, and it's the one we'd want before committing budget to anything here. The top-ranked item is a good example: thermal performance data is expensive and slow to generate, so we'd guess we have somewhere between 40 and 200 tests, not thousands. That's workable, but it rules out anything deep-learning-shaped and it changes the honest expectation of accuracy.

Now the content, which is where the real problems are

These aren't ten projects. They're four clusters.

• Formulation/process → property: strength (1), thermal (2), pass/fail (3), formulation recommendation (10)
• Vision inspection: defect filter (4), mixing (5), contamination (7)
• Sensor time-series: degradation (6), IR overheating (8)
• Documents: report drafting (9)

This reframing changes the economics completely, and a flat scorecard cannot show it. Within a cluster, the second project costs a fraction of the first, because the data pipeline, the validation approach, and the deployment path are already built. Across clusters, we start from zero every time.

Which means the strategic question isn't "which of these ten?" It's "which cluster do we build capability in first?" — and then we get items 2, 3, and 4 of that cluster cheaply.

Items 1, 2 and 10 are the same project

This is the biggest thing. Item 1 is a surrogate model: formulation and process → strength. Item 10 is that same model with an acquisition function on top, proposing the next experiment. Item 2 swaps the target property.

They're one pipeline with three outputs, not three separate initiatives.

The Data score of 1 on the vision items is probably wrong

Not wrong today. We scored the defect filter Data=1, almost certainly reasoning that we'd need hundreds of labelled defect images we don't have. That reasoning is correct for classification. But anomaly detection trains on good parts only and localises defects it has never seen. The data requirement collapses from "collect and label 500 defects over eighteen months" to "photograph 200 good parts next week."

So that item's Data score is realistically a 3, and its rank moves substantially..

Rule 1, applied honestly

In Rules of Machine Learning 1–10. Rule 1 says don't be afraid to ship without ML. Three of the items need that test run against them before anyone spends money:

IR overheating (8) — is this ML, or is it a thermal camera with a threshold alarm? If a fixed temperature limit catches the risk, we want instrumentation and a PLC, not a model. Cheaper, faster, explainable, and no drift.

Contamination in feedstock (7) — optical sorters are a mature commercial product. In recycling, this is largely a solved equipment problem. Buying may beat building by a wide margin.

Poor mixing from images (5) — the Feasibility 2 here is the best score on the sheet. We've asked "is the signal even present in this sensor modality?" Mixing quality is frequently sub-surface, so images may carry no information about it regardless of model sophistication. Most data scientists never ask that question; it's a physics judgement and it's ours to make. If mixing quality is what we need, inline torque or rheology probably beats a camera.

One item needs different treatment entirely

If "risk of overheating" has a safety dimension rather than a productivity one, it doesn't belong on this scale at all. Safety items can't be averaged alongside yield improvements, because the cost distribution of the tail event is categorically different, and if a model becomes a safety component of a regulated product, we're potentially a provider of a high-risk AI system under the EU AI Act's Annex I, with a completely different obligation set.

The gap to be filled

Nothing on this list touches recyclate, regrind variability, energy consumption in drying, extrusion, or curing (often the fastest payback in polymer processing), tool and die wear, and colour matching.

Now look back at the map. Items 1, 2, 3 and 6 replace measurements. Items 4, 5, 7 and 8 replace judgements. Only item 10 replaces a search. we had almost no "search" items and no soft sensors on incoming material, and that's exactly where the two gaps sit. It wasn't a knowledge gap, it was a category we hadn't thought to look in.

Feedstock variability as a soft sensor

We receive a lot of recyclate. To know whether it will run properly and what the finished part will do, we'd need to compound it, mould specimens, condition them, and test, days, sometimes weeks. So we don't. Instead we almost certainly do what everyone does: formulate for the worst case. Extra virgin content, extra stabiliser, a derated spec, wider process windows. We pay that insurance premium on every single lot, including the good ones.

The ML problem: predict the downstream property from a fast incoming measurement.

• Inputs: an NIR or FTIR spectrum of the incoming material (several hundred wavelength channels), MFI, bulk density, moisture, ash, colour as L*a*b*, supplier, contamination counts
• Output: impact strength, elongation at break, processability, or directly — the blend ratio needed to hit spec

Why can't we just write an equation? Because a spectrum is 500 collinear channels and there is no closed-form relationship from spectrum to impact strength. But there is a stable statistical one. This is the founding application of chemometrics, partial least squares regression has been doing exactly this since the 1980s, which makes it arguably the most mature ML application in materials science, older than the phrase "machine learning."

The value isn't the prediction. It's that we stop over-formulating. Every lot gets the blend it actually needs rather than the blend the worst lot would need. In recyclate-heavy products, that margin is often substantial, and it's currently invisible because it's spread thinly across every batch rather than showing up as a line item.

There's a second framing that connects to our Cluster 1: given the predicted incoming properties, what process settings hit target? That's the inverse problem, same surrogate-plus-optimiser architecture as our strength model, pointed at a different input. Not a new capability, a reuse.

Energy as three different problems

Let's apply Rule 1 to this suggestion: metering alone gets us most of the way, and if we don't currently have submetering on the major consumers, buy meters before we build models. That's the honest answer.

But once we have the data, three genuine ML problems appear:

1. Explanation, not prediction. kWh/kg isn't constant, it moves with product, line speed, ambient temperature and humidity, dryer loading, screw configuration, shift. A regression with SHAP separates the controllable drivers from the ambient ones and ranks them. Note what's happening: no model gets deployed. We learn something, change a setpoint, and throw the model away. That's a completely legitimate use of ML that most people overlook because there's no system at the end of it.
2. Optimisation under constraint. Minimise kWh/kg subject to meeting spec. Drying is the classic case: nearly everyone over-dries, because under-drying is catastrophic and over-drying merely costs money. Predict the required dry time from incoming moisture and ambient conditions, and we stop burning the safety margin. Curing ovens, same logic, over-cure is thermal energy spent for zero property benefit.
3. Anomaly detection using energy as the sensor. Rising kWh/kg at constant output is a leading indicator of mechanical degradation, wear, fouling, a failed heater band, a leaking valve. The meter is already installed, so this is nearly free condition monitoring.

And given our remit: energy is embodied carbon. If our customers are asking about Scope 2 or we're producing EPDs, kWh/kg has become a product attribute, not just a cost line. That reframing tends to unlock budget that "energy efficiency" doesn't.

What I'd actually do

Build Cluster 1, starting with strength (item 1), not thermal (item 2).

Our instinct says thermal, because it scores highest. It'd argue that strength first, for three reasons: the data for it is more plentiful and more standardised, the target is a single scalar rather than a possible spectrum, and it de-risks the pipeline that thermal will then reuse. Thermal is the payoff; strength is the proof. Getting that order wrong is how a flagship project becomes a cautionary tale.

Then item 10 falls out of it almost free, because it's the same model with an optimiser attached.

Run report drafting (9) in parallel, off the critical path. It scores 3.75 but the scorecard undervalues it, because it can't see political capital. It's low-risk, touches no production line, has no safety exposure, uses data we already own, and can run entirely on local open-weight models so nothing leaves the building.