3. Label engineering for industrial outcomes

In industrial prediction systems, the model is only as good as the label it is trained to predict. Unlike benchmark datasets where labels are curated and unambiguous, industrial labels must be constructed from raw operational data. This chapter covers the three decisions that determine whether a supervised model learns something useful or something misleading: how to define the target event, how to handle the delay between cause and observable outcome, and how to prevent information from the future leaking into the feature set.

3.1 Event Definition: Turning Continuous Operations into Discrete Targets

Industrial processes generate continuous sensor streams. A label requires a discrete, unambiguous event definition. Consider a rotating equipment monitoring scenario: a vibration sensor samples at 1 kHz, and the maintenance team wants to predict bearing failure within the next 72 hours. The raw data contains no column called "failure." That column must be engineered.

A workable event definition specifies four things: the failure mode (e.g., outer-race bearing spalling), the detection criterion (e.g., vibration RMS exceeding 4.5 mm/s sustained for 10 minutes, confirmed by inspection), the observation window (72 hours before the confirmed failure timestamp), and the negative sampling rule (what counts as a healthy example).

Ambiguity in any of these four dimensions produces label noise that no algorithm can overcome. If the detection criterion is "operator reported unusual noise," the label depends on human attention, shift patterns, and reporting culture — not on machine condition. A model trained on such labels learns to predict when operators file reports, not when bearings fail.

For the bearing example, a defensible predicate might be:

label = 1  IF  EXISTS inspection_record
              WHERE equipment_id = e
                AND fault_type = 'bearing_outer_race'
                AND inspection_ts BETWEEN t AND t + INTERVAL '72 hours'
label = 0  IF  equipment_id = e
              AND NO inspection_record with fault_type IN (...)
              AND equipment operated normally for the full 72h window

The negative class deserves equal rigor. "No failure occurred" is not the same as "we have no record of failure." Equipment that was decommissioned, taken offline for unrelated maintenance, or simply not inspected during the window should be excluded, not labeled as healthy.

3.2 Delay Handling: Aligning Cause and Effect in Time

Industrial outcomes are rarely instantaneous. A lubricant contamination event may take days to manifest as bearing degradation. A process drift may accumulate over weeks before quality inspection rejects a batch. The label timestamp — when the event was recorded — is almost never the timestamp when the causal process began.

Three delay types must be handled separately:

• Physical delay: the genuine time between cause and effect (e.g., crack initiation to spalling detection). This is the signal you want the model to learn.
• Detection delay: the time between the physical event and its recording (e.g., inspection scheduled weekly). This adds noise to the label timestamp.
• Reporting delay: administrative lag between detection and database entry. This is pure noise and should be corrected or bounded.

The standard approach is to define a prediction horizon and a label window. If the goal is to predict failure 72 hours in advance, then for a failure recorded at time T, the positive label applies to feature vectors computed in the interval [T − 72h, T). Feature vectors computed after T belong to the failure event itself and must not be used for training the predictive model.

Detection delay complicates this. If inspections occur weekly, the recorded failure time may be up to 7 days after the physical failure. A conservative correction is to shift the label window earlier by the maximum plausible detection delay, or to exclude the uncertain interval entirely. The choice depends on whether false negatives (missing a failure) or false positives (unnecessary maintenance) are more costly in the specific plant context.

3.3 Target Leakage Prevention: Keeping the Future Out of the Features

Target leakage occurs when a feature contains information that would not be available at prediction time. In industrial settings, leakage is often subtle and structural rather than accidental.

Common leakage patterns include:

The most reliable defense is a point-in-time correctness discipline: every feature must be computable using only data with timestamp strictly less than the prediction timestamp. This is analogous to the "as-of" join in financial data systems. In practice, this means maintaining an event-time index and never using ingestion-time ordering as a proxy for causality.

3.4 A Worked Example: Bearing Failure Prediction

Returning to the bearing scenario, suppose we have vibration RMS, temperature, and load readings at 1-minute intervals, plus a maintenance log with inspection records. The label engineering pipeline proceeds as follows:

1. Extract all inspection records with fault_type = 'bearing_outer_race' and a confirmed timestamp T_fail.
2. Define the positive label window as [T_fail - 72h, T_fail).
3. Define the negative window as any 72-hour period where the equipment operated continuously and no inspection record exists within ±7 days.
4. For each 1-minute timestamp t in a window, compute features using only data in [t - 24h, t).
5. Assign label 1 if t falls in a positive window, 0 if in a negative window, and exclude otherwise.

The resulting dataset has a clear temporal separation between feature computation and label assignment. A model trained on this data can be deployed with the same 24-hour feature window and 72-hour prediction horizon, and its performance will reflect genuine predictive capability rather than leakage.

The diagram above shows the temporal relationship between the feature window and the label window. The feature window ends at the prediction timestamp t; the label window begins at t and extends 72 hours forward. Any feature computed from data after t — including the failure event itself — falls into the excluded zone and must not enter the training set.

3.5 Validation Checklist

Before training any model, verify the following:

• Every positive label traces to a documented, timestamped event record.
• Every negative label comes from a period of confirmed normal operation, not merely absence of records.
• Feature computation windows are strictly left of the prediction timestamp.
• No join key or categorical feature is populated only after the outcome occurs.
• The base rate of positive labels is plausible for the physical process (e.g., bearing failures should not occur in 40% of windows).
• A univariate AUC scan shows no single feature with implausibly high separation.

Label engineering is not a preprocessing step to be rushed. In industrial systems, the label definition encodes the business objective, the maintenance policy, and the physical understanding of the failure mode. Getting it wrong produces models that are accurate on paper and useless on the floor.