This fictional exercise uses simplified timestamps and a sum feature. Real pipelines may have additional processing delays, corrections, time windows, and versioning requirements. See Google’s feature-serving documentation for point-in-time context.

1. Run the lab

Download point_in_time_lab.py and run it with Python 3. It uses only the standard library and makes no network calls.

python point_in_time_lab.py

The script calculates a per-customer sum at 10:00 UTC in three ways: using events that both happened and were available by the decision time; checking event time alone; and joining the current snapshot without a time cutoff.

2. Explain the totals

For customer A, the correct historical sum is 10. A second event worth 20 happened before the decision but did not arrive until 11:00, so the event-time-only join incorrectly produces 30. A third event worth 30 occurred after the decision; including it produces the current-snapshot total of 60. Customer B’s historical sum is 7.

YOUR TURN

Why can an event-time filter still leak information? If the pipeline took another ten minutes after arrival to publish the feature, which timestamp would you need to record?

Reveal the explanation

The event may have happened but still been unavailable to the serving system. Record when the feature was actually available to the decision, including processing and publication delays. Historical reconstruction must use the availability contract that applies to that serving path.

3. Extend the lab

  1. Move the late event’s availability time to 09:59 and predict the new historical total before running the script. Update the corresponding assertion too.
  2. Add a second decision for customer A at 13:00. Explain why the same entity can have a different valid feature value at a different decision time.
  3. Consider an event corrected the following day. What versions and timestamps would you preserve to reconstruct both what was originally known and the corrected record?

This example deliberately avoids claiming that a temporal join alone prevents every form of leakage. Define the prediction target, outcome horizon, and training split separately. Continue with point-in-time features and preprocessing parity.