Choosing Labels and Prediction Horizons for Market Models
Define what a model predicts, when that prediction is made and how its outcome connects to a measurable trading decision.

Start with a decision, not a convenient column
A label is the outcome a supervised model learns to predict. Before constructing one, state the decision the prediction is meant to inform. Is the model ranking instruments, estimating a return over a fixed horizon, classifying whether a threshold is crossed, or flagging a risk condition? These questions require different labels and evaluation methods. Avoid selecting a target simply because it is easy to calculate. Specify the decision timestamp, the entry assumption and the outcome horizon. A label that does not match the intended use can produce a technically correct model that answers the wrong question.
Make the horizon and threshold explicit
A future return label must identify its start and end points, price convention and treatment of trading sessions. If a classification threshold is used, document why it matters and whether costs are included. Short horizons may be dominated by spread and noise, while longer horizons can overlap across neighboring examples. Neither is universally better. Define how corporate actions, missing bars, market holidays and price limits are handled for the instruments in scope. Keep units clear: a percentage return, a point change and a binary threshold are not interchangeable. Recompute a sample of labels by hand to confirm that each value lines up with the intended timestamps.
Avoid accidental future information
Labels necessarily use future outcomes, but those future values must never slip into model features or preprocessing at prediction time. Ensure that each feature row is joined to the label for the correct observation and that the model only sees data available at its decision point. Be careful with rolling windows, delayed data publication and revised records. When outcomes overlap in time, a validation procedure may need to account for that dependence. Keep label generation code separate, named clearly and versioned. A review should be able to trace one row from raw prices through its feature timestamp, target window and final label without guessing.
Validate labels against the economic question
After calculating labels, inspect their distribution by period, instrument and market condition. Keep a small set of hand-checked examples with timestamps so a reviewer can verify the target construction without relying on the training pipeline. Check class balance, missing values and whether a few extreme observations dominate. Compare model scores with a simple baseline and evaluate how the score would be used after costs and execution constraints. If a model predicts a small positive return but expected friction is larger, that score may not support a viable action. Keep research conclusions narrow and report uncertainty. A well-designed target clarifies the experiment; it does not guarantee that a strategy based on the prediction will be profitable.