Feature engineering and preprocessing · insight-0128

Remove features that are recorded because of the outcome, not before it

Situation
A candidate feature is filled in by a process that happens after or because of the target event, such as a cancellation reason, refund amount or collections flag.
Action
For each feature, document who writes it and when relative to the prediction time; drop or time-shift any field written after the decision point.
Reason
Leakage arises when training data contains information about the target that would not be legitimately available when the model is used.
Boundary
Any supervised model built from operational systems, especially CRM, claims and support tools.

Symptom or risk

Near-perfect validation scores; the model is reading the answer, and the feature is empty or different at prediction time.

Post-outcome fields are fine for analysing outcomes or for a later-stage model whose decision happens after they exist.

Auditing timestamps for every column is slow; prioritize the most important features and any with suspiciously high importance.

Trusting a column name; a field called booking_status may be overwritten with the final status.

Synthetic airline case: a no-show model using cancellations from the final flight_day row learns the outcome itself.

Leakage is the introduction of information about the target that should not legitimately be available to the model at prediction time.
Leakage in data mining: Formulation, detection, and avoidance