The shop’s rainy-evening question
The shop from Lesson one has a rule that estimates delivery cost from distance. On a rainy evening, its estimates are consistently too low. Before changing the rule, what information was available when each quote was made, and what did each delivery actually cost?
This is Module one, Lesson two: Examples, features, labels, and datasets. By the end, you should be able to read a small training example, separate a feature from a target, spot information that arrives too late to use, and diagnose a data problem before asking for a more complex model.
We'll follow one delivery through three stages: build an example, check when its information exists, and inspect what its dataset represents. Then we'll return to the rainy-day error.
Build one training example
An example is one unit presented to the learning process. For our shop, one completed delivery can be an example. It might record a distance of five kilometers, a travel time of twenty minutes, a van as the vehicle, and an actual operating cost of twelve dollars.
A feature is an input variable the model uses to make a prediction. Distance can be a feature. Vehicle type can be another. The target, also called a label in supervised learning, is the outcome the model is trying to predict. For a delivery-cost model, the actual cost could be the target.
Picture a row in a table. Its feature columns hold the information offered to the model. Its target column holds the answer used to judge the prediction during training. For one row, the model receives five kilometers and van. It might predict ten dollars, while the recorded target is twelve dollars. The difference gives the learning procedure evidence about its current rule.
Assign roles for the task
The input and target roles depend on the task. If we want to predict travel time, actual travel time becomes the target. If we want to estimate delivery cost before dispatch, actual cost is a target available later for learning, not an input available at quote time. Name the task before deciding which column has which role.
Collect examples into a dataset
A dataset is a collection of examples. Hundreds of rows could represent hundreds of deliveries. Rows and columns are a helpful picture for these records. Images, audio and sequences may use other structures, but we still need to ask what the model can know when it must act and what outcome it is asked to learn.
Check prediction-time availability
Now put the shop's quote time on a clock. Distance and a planned vehicle may be known before dispatch. Actual fuel used and the final invoice arrive after delivery. A feature is useful in a deployed predictor only if it is available, with the same meaning, when the real prediction will be made.
Recognize target leakage
Suppose an analyst includes final invoice total as a feature while training a model to predict that invoice total. The model may appear astonishingly accurate because the answer is already in its input. It cannot repeat that performance when asked for a quote before the invoice exists.
That is target leakage: information about the target has entered the features in a way that would not be available for the intended prediction. Leakage can be less obvious than copying the answer. A status field recorded after a fraud investigation, or a travel duration measured only after the van returns, can quietly reveal what happened later.
Some fields are useful for explaining past mistakes but unusable as live inputs. The final invoice helps us assess the quote. It does not become a valid feature simply because the spreadsheet contains it. To simulate deployment honestly, build each training row as it would have looked at the prediction time, then compare the prediction with the later target.
Ask how labels were produced
The word label can make a recorded outcome sound like unquestionable truth. Look instead at how it was produced. Our shop's actual cost may include driver time and fuel, but perhaps one depot includes loading labor and another does not. A cost model trained on both definitions learns from inconsistent targets.
In a fraud system, a label of confirmed fraud may require an investigation. A transaction never investigated may remain unlabeled even if it was fraudulent. A customer rating may reflect taste, a confusing interface or an incentive to rate. A medical label may depend on whether someone was tested and followed up. Each target is evidence made by a process, and the process can leave gaps or distortions.
Treat missing values as evidence to investigate
Missing feature values have histories too. If travel time is blank, did a sensor fail? Was the route unavailable? Was the order canceled before travel? Entering zero minutes for every blank cell says all those events mean no travel. That could teach the wrong relationship.
A team might investigate the source of missingness, preserve a separate missing indicator, omit some cases for a justified reason, or estimate a value where that is defensible. The choice depends on the task and on what will happen at prediction time. Preparation is part of the model design, not a clerical cleanup after the important work.
Preserve numerical and categorical meaning
Distance is numerical: six kilometers is twice three kilometers. Vehicle type is categorical: van and bike name kinds of vehicle. Suppose a database codes van as one and bike as two. Bike is not twice van. Those digits are labels for categories, not a meaningful scale.
If a model treats the codes as amounts, it may infer an order or distance between categories that we never intended. A suitable representation might give each vehicle its own indicator, or use another encoding chosen for the model and available data. The point is to preserve the field's meaning when turning it into a form a model can process.
Units matter for numerical features too. Lesson one showed that five miles entered as five kilometers produces a tidy but mistaken calculation. Consistency across examples and live inputs matters as much as the arithmetic.
Inspect dataset quality and coverage
We can now inspect the dataset as a whole. Are the records accurate and relevant? Do they cover the routes, times, vehicles and weather the shop actually faces? Were the fields measured consistently? Are they recent enough for today's operation? Does the shop have permission to use them for this purpose?
A perfectly formatted table can still describe the wrong population. If all training deliveries were short city trips, its performance may tell us little about long rural routes. A very large dataset can still omit rare but costly storms. More rows help only if their information and the chosen learning objective serve the real task.
Investigate the rainy-day error
Return to rainy evenings. The model underpredicts. One possibility is that the features do not include rain, so the model cannot distinguish wet and dry conditions at the same distance. Another is that rainy deliveries exist but are rare or absent in training. A third is that recorded costs use different definitions across drivers or seasons. The relationship itself may have changed because of traffic or fuel prices.
Those explanations suggest different checks. Inspect available weather information at quote time. Count rainy examples in training and in recent operations. Audit cost definitions. Compare errors over time and across groups of deliveries. Adding more model parameters before checking these facts could leave the actual cause untouched.
Check your understanding
The analyst finds that final travel time strongly predicts actual cost. Why might it be useful in an after-the-fact analysis but invalid as a feature for a quote made before dispatch?
Final travel time is observed only after the trip. It can help explain past costs, but a live quote does not have that value. Training with it and evaluating as though it were available would create an unrealistic test of the intended use. We could use an estimate of travel time made before dispatch, if that estimate is genuinely available then, but it is a different field with different errors.
The shop then finds a blank travel-time value. Should it automatically replace the blank with zero?
No. A blank may mean failed measurement, canceled delivery, or something else. Zero minutes has its own meaning. We need to learn why the value is missing and choose a preparation rule that makes sense for training and live use.
Put the distinctions together
We built one delivery example, separated information offered to the model from the target it learns to predict, and placed a clock between them. We examined where labels and missing values come from, why a category code is not automatically a quantity, and whether the dataset covers the shop's real work.
The rainy-day error is a prompt to inspect features, examples, definitions and change over time. A more complicated rule cannot recover information that was never available or represented. On the ecosystem map, this is the data work that sits before and beside model training. The organization decides which information can be collected and used, and evaluation later checks whether the resulting system helps people make better decisions.
Continue to loss
In Lesson three, we will take a prediction and its target and assign a numerical penalty to their mismatch. That penalty, called loss, tells a learning procedure what it is trying to improve. The data we just examined gives that calculation its meaning.