Features and Labels

You already use features and labels. You just call them something else.

Every engineer works with inputs and outputs.

You set process parameters — feed rate, spindle speed, depth of cut — and measure the result: surface roughness. You vary alloy composition — carbon, manganese, chromium content — and test the outcome: tensile strength. You adjust design variables — wall thickness, fillet radius, material choice — and run a simulation to get: maximum stress.

In every case, you have inputs that you control or measure, and an output that you're trying to predict or understand.

Machine learning uses exactly the same structure. It just has its own names for these things:

That's it. If you understand inputs and outputs, you understand features and labels.

You'll see these two words in every ML tutorial, every scikit-learn documentation page, and every data science blog post you'll ever read. They're the vocabulary you need to speak the language. But the concept behind them is something you've been using your entire career.

Features: the information your model gets to work with

Features are the columns of data you feed into a model. They're the information the algorithm is allowed to look at when making a prediction.

In a CNC machining problem, your features might be:

• Feed rate (mm/rev)
• Spindle speed (rpm)
• Depth of cut (mm)
• Tool wear (mm)
• Coolant flow rate (L/min)

In a materials science problem:

• Carbon content (%)
• Manganese content (%)
• Tempering temperature (°C)
• Hold time (min)
• Cooling rate (°C/s)

In an FEA surrogate problem:

• Wall thickness (mm)
• Fillet radius (mm)
• Applied load (N)
• Young's modulus (GPa)
• Part length (mm)

Each of these is a feature. Each row in your dataset — one specific combination of these values — is called a sample (or sometimes an observation or instance). So if you've run 500 FEA simulations with different parameter combinations, you have 500 samples and however many columns of input parameters you varied — those are your features.

Labels: what you're trying to predict

The label is the output column — the value the model learns to predict from the features.

In supervised learning (where most practical engineering ML lives), you need labels in your training data. The model learns by looking at historical examples where you already know both the inputs and the output. Then it applies what it learned to predict the output for new inputs where you don't yet know the answer.

Where do labels come from in engineering? Usually from one of these sources:

Physical measurements. You measured surface roughness after each machining run. You tested tensile strength on each specimen. You recorded the pass/fail result of each inspection. These measured outcomes are your labels.

Simulation outputs. You ran 500 FEA simulations and recorded maximum stress for each combination of design variables. The stress values are your labels. The design variables are your features.

Expert judgement. An experienced operator classified vibration signals as "healthy," "watch," or "replace." A welding inspector graded each weld. These human assessments become labels that a model can learn from.

Existing records. Your company's quality database already contains years of production data with outcomes attached — scrap rates, rework flags, customer returns. This historical data is a goldmine of labels.

The quality of your labels matters enormously. If your measurements are noisy, your model will be noisy. If your expert's classifications are inconsistent, the model will learn that inconsistency. The old computing maxim applies: garbage in, garbage out. But in engineering, you're used to that — you'd never trust a calibration curve built from unreliable measurements either.

The notation you'll see everywhere: X and y

Open any ML tutorial, any scikit-learn example, any textbook — and you'll see this:

                        X = the features  # a table with rows and columns
y = the labels  # a single column of outputs
                    

That's it. X is the matrix of input data (capital letter because it has multiple columns). y is the vector of outputs (lowercase because it's a single column).

In scikit-learn, every model follows the same two-line pattern:

                        model.fit(X_train, y_train)  # Learn patterns from training data
predictions = model.predict(X_new)  # Predict labels for new data
                    

This notation can feel alien at first if you're used to engineering variable names. But it's worth learning because it's universal. Every ML library uses it, every tutorial assumes it, and once you're comfortable with it, you can read any scikit-learn documentation page and immediately understand what's going on.

When you see X in ML code, just mentally translate it to "my input table — the features." When you see y, translate it to "the output column — the thing I'm predicting." That translation will carry you through every algorithm we cover in this knowledge base.

Choosing the right features is an engineering superpower

Here's where your domain expertise becomes your biggest advantage over any data scientist.

A data scientist looking at a manufacturing dataset sees columns of numbers. You see physics. You know that feed rate and depth of cut interact to determine chip load. You know that spindle speed and tool diameter together determine cutting velocity. You know that the ratio of two columns might be more meaningful than either column alone.

This kind of knowledge — understanding which variables actually matter and how they relate physically — is called feature engineering in ML. And it's one of the most important steps in building a good model.

Some practical examples:

Creating meaningful ratios. Instead of giving the model wall thickness and applied load as separate features, you might also include their ratio (a proxy for stress). The model could learn this relationship on its own, but giving it a head start with physics-informed features often improves performance dramatically.

Extracting statistics from raw signals. If you have vibration time-series data, you wouldn't feed the raw waveform into a tabular ML model. Instead, you'd extract features like RMS amplitude, peak frequency, kurtosis — quantities that capture the character of the signal. Your engineering knowledge tells you which statistics are physically meaningful.

Removing irrelevant columns. Your dataset might include a timestamp column, an operator ID, or a batch number that has no physical relationship to the output. Including these can actually hurt model performance by introducing noise. You know which columns are physically relevant — a data scientist working without domain context might not.

A note on terminology: labels, targets, and other synonyms

ML has an annoying habit of using multiple words for the same thing. You'll encounter all of these, and they all mean the same:

For the output (the thing you predict): label, target, response variable, dependent variable, y.

For the inputs (the information the model uses): features, predictors, independent variables, input variables, attributes, X.

Don't let the vocabulary trip you up. If you see a new term and you're not sure whether it means "input" or "output," that's almost certainly what it is. The concepts are simple — it's only the naming that's messy.

In this knowledge base, we'll mostly use features and labels because they're the most common terms in modern ML. But we'll use engineering language ("input variables," "output," "prediction") interchangeably so you build fluency in both.

A quick self-test

Before moving on, try this exercise with a real problem from your own work. Pick any engineering task where you use data to make a decision, and fill in the blanks:

If you can fill this in for even one problem from your job, you've just defined your first ML project. You might not know which algorithm to use yet — that's fine, we'll get there. But you've taken the hardest first step: framing an engineering problem as an ML problem.

Key takeaways

Features are your inputs. Labels are your output. In engineering terms: features are the process parameters, design variables, or measurements your model looks at. The label is the outcome it's trying to predict.

Your data is already structured this way. Every spreadsheet of test results, every simulation DOE, every production log — columns of inputs and a column of results. That's features and labels.

The standard notation is X (features) and y (labels). Learning this convention unlocks every ML tutorial, documentation page, and code example you'll encounter.

Feature engineering is where your expertise shines. Knowing which variables matter, how they interact physically, and what ratios or derived quantities are meaningful — that's domain knowledge a generic data scientist doesn't have. It's your unfair advantage.