Data Preparation

Reconstruct the prediction-time report

Move the prediction earlier

The sensor export contains measurements from after the repair decision. Botie must restrict the prediction to evidence available at its cutoff.

BOTIE

The cutoff is hour 8 and availability times are [6, 8, 10, 14]. Which measurements may enter this prediction?
The inputs we are comparing

Availability hours

Noon prediction

  1. 09
  2. 112
  3. 218

Earlier prediction

  1. 06
  2. 18
  3. 210
  4. 314

Prediction cutoff hour

Noon prediction

12

Earlier prediction

8

Corresponding measurements

Noon prediction

  1. 019
  2. 122
  3. 299

Earlier prediction

  1. 011
  2. 113
  3. 217
  4. 321
Result for noon prediction
  1. 019
  2. 122
Choose an explanation to test
The export is not in time order

This check uses the pieces from “Keep evidence on the available side of the cutoff”.

BOTIE

The export mixes late and early records, with two measurements available exactly at the cutoff. Predict the values that were available for the prediction, preserving export order.
Availability hours
  1. 014
  2. 17
  3. 210
  4. 310
Prediction cutoff hour
10
Corresponding measurements
  1. 099
  2. 112
  3. 217
  4. 318

Use a number, text, or an array matching the requested result. For a matrix, put each row in brackets. Saving your prediction runs your current construction on these inputs and checks the earlier examples too.

Build a construction in the workspace above first. This case will test those pieces.

Why can a highly predictive measurement still be unusable, and what timing details would a real export need beyond whole hours?

Define the prediction moment before choosing features, then track when each feature truly becomes available.

Times are simplified whole hours. A real system also needs dates, time zones, ingestion delays, and update history.

Work through the Python challenges →
Continue the courseWhen the Important Class Is Rare →
← When the End Is Beside the Beginning