What Is Machine Learning?

The one-sentence version

Machine learning is a way of building systems that learn rules from data, rather than having a human write those rules explicitly.

That's it. That's the core idea. Everything else — the algorithms, the maths, the frameworks, the breathless LinkedIn posts — is detail on top of that single concept.

But "learning rules from data" is a phrase that sounds simple and turns out to be enormously powerful, so let's unpack what it actually means. Especially if you're an engineer or technician who works with processes, equipment, or physical systems — because that context changes which parts of ML matter and which you can safely ignore.

The way you normally solve problems

Think about how engineering problems typically get solved. You observe a system, you develop understanding of how it works, and you translate that understanding into explicit rules.

A structural engineer knows that if the bending stress in a beam exceeds the yield strength of the material, the beam will fail. That's a rule derived from physics. It's written into design codes. You can look it up in a table. A process engineer knows that if the reactor temperature drops below a certain threshold, the chemical conversion slows down. That's a rule derived from chemistry and thermodynamics.

Software works the same way. When you write a traditional program, you encode rules explicitly:

You — the engineer — figured out the thresholds. You wrote the logic. The computer just executes it.

This approach works brilliantly when the rules are known, stable, and relatively simple. Most of engineering runs on it, and there's nothing wrong with that.

But sometimes the rules aren't known. Or they're too complex to write down. Or they shift over time. That's where machine learning comes in.

What ML does differently

With machine learning, you flip the process around. Instead of writing the rules yourself, you give the system a pile of examples — data — and let it figure out the rules on its own.

	Traditional programming	Machine learning
You provide	Data + Rules	Data + Answers
The system produces	Answers	Rules
Who writes the logic?	You, the engineer	The algorithm, from examples

In traditional programming, you hand the computer rules and data, and it gives you answers. In machine learning, you hand it data and answers, and it gives you rules.

That's the inversion. And it's more profound than it sounds.

A concrete example: weld quality

Imagine you work in a factory that produces welded assemblies. Some welds pass quality inspection, some don't. You have years of production records: welding current, voltage, wire feed speed, gas flow rate, travel speed, ambient temperature, material batch — and for each weld, the inspection result: pass or fail.

The traditional approach is to have an experienced welding engineer examine the data, identify the critical parameters, and write rules: "If the current drops below 180A at a travel speed above 35 cm/min, the weld is likely to fail." This works if the relationships are simple and the engineer has deep enough domain knowledge.

The machine learning approach is different. You feed all those historical records — thousands of them — into an algorithm. The algorithm analyses the data and discovers the patterns itself. Maybe it finds that the interaction between wire feed speed and ambient temperature matters more than anyone expected. Maybe it discovers a subtle threshold that no human had noticed because the relationship involves four variables at once.

The result is a model — a mathematical function that takes in the welding parameters for a new weld and predicts whether it will pass or fail. You can think of it as an equation the algorithm wrote, based on the examples you gave it.

What "learning" actually means

The word "learning" makes it sound like the machine understands something. It doesn't. There's no comprehension, no intuition, no intelligence in the human sense. What actually happens is much more mundane — and much more useful to understand clearly.

An ML algorithm starts with a mathematical structure — an equation with adjustable parameters. During training, the algorithm tweaks those parameters until the equation's outputs match the known answers as closely as possible. That process of iterative adjustment is what we call "learning."

Think of it like curve fitting — something every engineer has done. You have a set of data points, you choose a function (a line, a polynomial, an exponential), and you adjust its parameters to minimise the distance between the curve and the data. ML does essentially the same thing, but with more powerful functions, more dimensions, and more sophisticated methods for finding the best fit.

What can ML actually do?

Most practical ML boils down to a few types of task. You don't need to understand the algorithms yet — that comes later in this series. But knowing the categories helps you recognise where ML might apply in your own work.

Predict a number. Given a set of inputs, predict a continuous output value. What will the compressive strength of this concrete mix be? How many units will we sell next quarter? What's the remaining useful life of this bearing? This is called regression.

Predict a category. Given a set of inputs, assign something to a group. Will this weld pass or fail? Is this vibration pattern normal, suspect, or critical? Is this email spam or not? This is called classification.

Find groups in data. Without knowing the categories in advance, discover natural groupings. Are there distinct operating modes in our production data? Can we segment our products by failure pattern? This is called clustering.

Detect anomalies. Flag data points that look unusual compared to the rest. Did a sensor just produce a reading that doesn't fit the normal pattern? Is this machine behaving differently from yesterday? This is anomaly detection.

That's it. Regression, classification, clustering, and anomaly detection cover the vast majority of engineering ML applications. If someone tries to sell you something more complicated for a problem that fits one of these four categories, be sceptical.

When does ML make sense — and when doesn't it?

ML is not a universal hammer. It's a specific tool for specific situations. Here's an honest assessment of when it earns its place.

ML makes sense when:

• You have enough historical data to learn from (typically hundreds to thousands of examples, not a handful).
• The rules are complex, unknown, or hard to express explicitly — like predicting product quality from dozens of interacting process parameters.
• The patterns might change over time, so hard-coded rules would go stale.
• A human expert could make the judgement call given enough time, but you need it faster or at scale — like inspecting thousands of parts per hour.

ML does not make sense when:

• The rules are already known and work well. If a physics equation solves your problem, use the physics equation. It's more interpretable, more reliable, and doesn't need training data.
• You have very little data. ML algorithms need examples to learn from; they can't conjure knowledge out of thin air.
• The consequences of being wrong are severe and you need guaranteed correctness. ML models are probabilistic — they make predictions, not proofs.
• The problem is simple enough to solve with a lookup table, a threshold, or an IF-THEN rule. Don't use a bulldozer to plant a flower.

What machine learning is not

Since we're clearing the air, let's address some common misconceptions. These are particularly persistent because the popular conversation about AI tends to conflate very different things.

ML is not artificial general intelligence. Your model doesn't "understand" your process. It found a mathematical pattern in data. It can't reason, generalise to new domains, or adapt to situations it hasn't seen. It does one thing — the thing it was trained on.

ML is not just ChatGPT. Large language models are one branch of ML, but they're a very specific (and recent) branch. The ML that matters most for engineering applications — regression, classification, anomaly detection — has been around for decades and doesn't require massive computing resources. You can train a useful model on your laptop.

ML is not a black box by definition. Some models are inherently transparent. A decision tree, for example, is literally a flowchart you can read end to end. Other models are less interpretable, but there are techniques to explain any model's predictions. We'll cover both in later articles.

ML is not magic. It's applied statistics and optimisation. The maths behind most practical ML algorithms is well-understood and decades old. What changed is the availability of data, the computing power to process it, and the software libraries that make it accessible without a PhD.

Where this is going

This article gave you the mental model: ML learns rules from data. That's the foundation everything else builds on.

In the next article, we'll look at features and labels — the inputs and outputs of an ML model. Once you understand that your process parameters are features and the thing you're predicting is the label, you'll start seeing ML opportunities everywhere in your engineering work.

From there, we'll cover how you test a model honestly (and why testing on your training data is like marking your own exam), the difference between supervised and unsupervised learning, and the distinction between regression and classification. Five articles total to build a solid conceptual foundation — no code, no maths, just the ideas you need before the algorithms make sense.