Features, Labels, and Models: One Order at Two Moments

An order is placed at 10:03. The customer wants to know whether it will arrive tomorrow.

By next week, the order’s database row will contain a wealth of information: the chosen warehouse, the dispatch time, the carrier’s scans, and the actual delivery time. But at 10:03, much of that information does not exist.

That gap between the completed record and the prediction moment is a useful way to understand the basic parts of machine learning.

What we know, and what we want to know

Here is a small invented dataset. Assume warehouse assignment and the distance estimate are available when each order is placed. The final column is filled in later.

Order	Distance estimate, km	Items	Weekend order	Delivered next day
A	12	1	No	Yes
B	240	3	No	No
C	35	2	Yes	No
D	18	2	No	Yes
E	90	1	No	Yes

The middle columns are features: the inputs we propose to use. The last column is the label, or target: the outcome we want to predict. The order identifier lets us track records; we would not automatically treat it as a useful predictive feature.

You will often see these written as X and y. X contains the input columns for all the examples. y contains their target answers. These symbols are bookkeeping, not additional concepts.

Five invented orders cannot establish a useful delivery predictor. The table exists to show the structure of the problem.

An algorithm produces a model

A training algorithm is a procedure for fitting a decision function from examples. The fitted result is the model.

For example, a decision-tree algorithm might search for splits based on distance, item count, and weekend status. Once training is complete, the resulting tree contains particular conditions and predictions. That particular tree is the model; the procedure that found it is the algorithm.

At prediction time, a new order supplies the same kinds of input features. The model produces an estimate without receiving the future delivery result. Later, when the order arrives, we can compare the estimate with the outcome.

This is why training and inference should not be used interchangeably. Training fits the model. Inference applies it. Updating it after new deliveries requires an explicit update process.

The tempting column that breaks the exercise

Now add hours_from_order_to_delivery to the table. A model could use it to predict next-day delivery almost perfectly because it contains the answer in another form.

It is also unavailable at checkout. A test built from completed database rows might look impressive while describing a system that cannot operate in practice. This is data leakage: information enters the learning or evaluation process that would not legitimately be available for the intended prediction.

The remedy starts with a sentence, before any algorithm: Predict next-day delivery at the moment the customer places the order. That sentence determines which columns are allowed.

A second sentence defines the label: does “next day” mean the next calendar day, the next working day, or within 24 hours? The model cannot resolve that ambiguity for us.

Features and labels are often introduced as two groups of columns. In real work, they also represent a contract about time and meaning. Getting that contract right is more valuable than memorizing the notation.