Frame an ML Problem Before Training a Model

A machine learning project starts with a decision, not an algorithm list. “Predict equipment faults” leaves important questions unanswered: which equipment, what counts as a fault, when must a prediction arrive, and what action follows it?

This first lesson in the Machine Learning Engineer learning path turns a vague idea into a testable problem. You need basic Python functions, files and command-line familiarity. We introduce the project contract here; later lessons build the pipeline and evaluation around it.

The accompanying capstone uses synthetic sensor observations and a real scikit-learn classifier. It teaches a workflow, not industrial fault detection. Its fictional labels and scores do not establish performance on real equipment.

Write the prediction contract

A useful contract names the unit of prediction, decision time, allowed inputs, target, label availability and action. For our example, the unit is one synthetic observation. Temperature, vibration, load and pressure are available at measurement time. The target is a simulated fault during the next shift, declared available eight hours later.

That timing matters. An engineer cannot use a repair note written after a fault to predict the fault beforehand. Even a field with a harmless name can contain future information if its actual collection time is wrong. Write down availability, not just column names.

The decision also needs an owner. Would a positive prediction create an inspection request, stop a machine or merely appear in a dashboard? Those actions have different consequences. Our project stops at returning an educational classification; it does not control equipment.

Decide whether ML is needed

Start with an understandable rule or baseline. A simple rule might flag a vibration threshold. A statistical baseline could always predict the majority class or the training-set class probability. These approaches establish whether a more complicated model adds useful information under the chosen evaluation.

The capstone includes a scikit-learn DummyClassifier that predicts the training class prior. It is a comparison point, not a real monitoring policy. A model that improves on it on synthetic data has demonstrated something about this fixture only.

Do not confuse a more sophisticated algorithm with a better system. Labels may be unreliable, actions may be too costly, or the required information may not exist at prediction time. In those cases, a larger model does not resolve the underlying problem.

Choose the learning problem and success criteria

Binary classification predicts one of two classes. Regression predicts a numeric quantity. Ranking orders candidates. Clustering groups examples without a supplied target. Pick the formulation that matches the decision rather than forcing every dataset into classification.

Our classifier returns both a probability estimate and a class chosen by a threshold. These are different outputs. The probability can support several action policies; the threshold represents one particular decision rule. Later lessons examine precision, recall, calibration and threshold selection.

Agree on a primary evaluation objective and practical constraints before examining the final test result. For a real inspection workflow, false negatives, unnecessary inspections, capacity limits and label delays could matter more than a single score. The example uses validation F1 for teaching and explicitly does not claim that F1 is the right safety or business objective.

Learn mathematics when it explains the model

You need working understanding of vectors, averages, variation, conditional probability and loss. As you build a linear model, connect features to a weighted sum. When studying optimization, connect derivatives and gradients to how a loss changes. Study deeper matrix decompositions when the chosen methods require them.

This is not permission to ignore mathematics. It is a way to avoid postponing every project until you have completed an entire mathematics syllabus. You should be able to explain the assumptions and outputs of the model you actually use.

Exercise: inspect the feature contract

Download the versioned ML capstone, extract it, and use the README setup instructions. From its directory, run:

python - <<'PY'
from ml_capstone import FEATURES, HERE, load_data
rows = load_data(HERE / "sensor_events.csv")
print(len(rows))
print(FEATURES)
print(rows[0]["measured_at"])
print(rows[0]["label_available_at"])
PY

Expect 600 rows, four allowed feature names and timestamps eight hours apart. The identifier, timestamps and label are not model inputs. Write a one-page contract explaining why, then propose one useful baseline and one reason the project might not need ML.

You are ready to continue when someone else can identify the decision, target, input availability and limitations from your contract. Next, learn how to separate data so the evaluation respects that contract.

Sources and method

This lesson uses documentation research plus commands checked against our local synthetic capstone on Python 3.12.14 and scikit-learn 1.8.0. No real equipment data or production deployment was tested.

• scikit-learn: common pitfalls and recommended practices.
• scikit-learn: model evaluation.
• Python tutorial for prerequisite gaps.