Naming the task picks the evaluation
The first decision in an ML project is the task family. It fixes the target shape, metric, legal split strategy, and baseline. This is not taxonomy trivia; it is part of the contract that determines whether the experiment answers the product question.
The seven families you will see most
- Regression predicts a number on a continuous scale: price, demand, or latency.
- Binary classification estimates one of two outcomes, usually through a probability: churn, fraud, or click.
- Multi-class classification chooses one of K labels, such as digit or intent.
- Multi-label classification assigns any subset of labels, such as article tags.
- Ranking orders items for a user, as in search or recommendation.
- Forecasting predicts future values from temporal history.
- Anomaly detection scores rare or unusual behavior for investigation.
Do not name the task from the screen
A UI that eventually shows yes or no does not force binary classification. If sales can call only thirty customers, ordering the best thirty may matter more than labeling everyone. Capacity next week is a forecasting problem, and a risk score can support several cost-dependent actions. Name the task from the decision the system must make.
The wrong family quietly breaks the metric
Classification accuracy does not tell you whether the top thirty leads are ordered well. Randomly shuffling time-series rows lets future patterns leak into past training. On a rare-anomaly problem, a model that finds nothing can win on overall accuracy. The code still runs and the number still looks respectable, which makes framing errors especially dangerous.
Check it in one sentence
Write: for whom or what, predict which output, at what time, to support which action. The sentence should reveal whether the output is a number, probability, ordered list, label set, or future curve. If teammates name different task families from the same sentence, align the product decision before modeling.