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 inputs we are comparing
Availability hours
Noon prediction
- 09
- 112
- 218
Earlier prediction
- 06
- 18
- 210
- 314
Prediction cutoff hour
Noon prediction
12
Earlier prediction
8
Corresponding measurements
Noon prediction
- 019
- 122
- 299
Earlier prediction
- 011
- 113
- 217
- 321
Result for noon prediction
- 019
- 122
The export is not in time order
This check uses the pieces from “Keep evidence on the available side of the cutoff”.
BOTIE
- Availability hours
- 014
- 17
- 210
- 310
- Prediction cutoff hour
10
- Corresponding measurements
- 099
- 112
- 217
- 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 →