Rebuild What the Model Could Have Known

Historical Retrieval Needs a Time Boundary

BOTIE

A corrected reading can tell us more about yesterday while still being something we did not know yesterday. Database researchers had to represent that distinction long before it became a training-data problem. In their 1986 paper, Snodgrass and Ahn separated when a fact applied in the world from when it was recorded in a database. Keeping both lets us ask what was believed at an earlier time, even after a correction.

Machine-learning teams face a related difficulty when rebuilding inputs for old predictions. Feast, announced by Gojek and Google Cloud in 2019, provided a shared feature store for training and serving. Its historical retrieval selects feature values against each training row's timestamp rather than attaching today's value to every old example.

Our lesson keeps an additional availability timestamp explicitly. A measurement may describe an earlier event but arrive after the prediction. We must check both boundaries to reconstruct what the service could have used. That extra rule is part of this example's contract; a feature store's point-in-time label alone does not promise it.

Sources for this history

Today’s Database Knows Tomorrow’s Answer

We want to train Botie using yesterday’s decisions. Today’s feature table contains corrections that arrived after those decisions. Joining each decision to the latest record would give the training model information its deployed counterpart never had.

We need to reconstruct the information boundary for each decision. First decide which records existed, then choose the latest event among those records.

One entity with valid timestamps is supplied; this stage returns eligible rows, not the final selected feature.

Step 1 of 1

A correction arrived too late

The decision happened at time 10.

Only values 20 and 18 were available. Of those, 20 has the latest event time.
Value	Event time	Available at
20	8	9
30	9	12
18	6	7

20
Event time
8
Available at
9
30
Event time
9
Available at
12
18
Event time
6
Available at
7

Only values 20 and 18 were available. Of those, 20 has the latest event time.

Keep the observation and its arrival separate

Filtering preserves eligible versions for later latest-event selection.

Exclude the future correction

Botie needs the records that existed at a historical decision.

BOTIE

Botie needs the records that existed at a historical decision.

Choose an example

Event times

1

2

Availability times

1

2

Aligned feature values

1

2

Decision time

Eligible feature values

010
120

Follow the operations

1. Aligned feature values
1. 010
2. 120
2. Decision time
```
5
```
3. Event times
1. 02
2. 14
4. Threshold gate
1. 01
2. 11
5. Availability times
1. 03
2. 15
6. Threshold gate
1. 01
2. 11
7. Multiply
1. 01
2. 11
8. Select real entries
1. 010
2. 120
9. Result
1. 010
2. 120

One entity with valid timestamps is supplied; this stage returns eligible rows, not the final selected feature.

1. Keep the observation and its arrival separate

Event time describes when the feature refers to. Availability time describes when the serving system could use that version. A late correction can have an early event time and a late availability time.

For multiple assets, first group records by asset identity, then make the selection within each group. This grouping is the partition used by the query. Otherwise the newest reading may belong to a different pump.

Retain historical versions. A table that overwrites every correction cannot reconstruct earlier knowledge merely by adding a query filter.

2. Filter first, then select the latest event

Both timestamps must be at or before the decision. Of the surviving rows, choose the greatest event time. Our coding contract breaks event-time ties by latest eligible availability, then by input order.

decision = 10
events = [8,9,6]
availability = [9,12,7]
eligible mask = [1,0,1]
eligible values = [20,18]
selected latest event value = 20

The workshop exposes the eligibility stage. The Python challenge completes selection and handles the no-record case.

Retain the late record in the history

The row is retained in raw history even when it is unavailable to a particular decision.

Python

record = {"event":9, "available":12, "value":30}
print(record["available"] <= 10)

Output

False

Rejecting it for this decision does not mean deleting a correction that later decisions may use.

Check yourself

Which clock permits this feature?

Question 1 of 2

Can the decision use this value?

Use the information below.

Decision 10; event 9; available 12.

3. Freshness asks a different question

A record may have been available but be too old for the task. A maximum age compares the decision time with event time. Define that duration in the feature contract.

Availability histories depend on trustworthy timestamps. Clock uncertainty or ingestion bugs need investigation; a precise comparison over incorrect clocks is still incorrect.

A missing eligible feature should trigger a declared fallback rather than pulling a later record into the past.

4. Replay the online procedure

Use the same entity keys, units and freshness limits in training and serving. Replay a small decision log against recorded historical inputs and compare chosen feature identities.

Keep the selected version ID in the audit trail. Matching a numerical value alone can hide a join to the wrong record.

This reconstructs data eligibility. It does not prove labels, measurement quality or evaluation splits are correct.