Anchor Time and Data Leakage

Anchor time is the boundary between information available to a model and the future period it predicts. Correct table timestamps and anchor times prevent future information from leaking into training, evaluation, or prediction.

Understand the temporal boundary

For a row with a time column, Kumo treats information at or before the anchor time as known context. Events after the anchor time are future information.

For a temporal predictive query, the prediction window begins after the anchor time. For example:

PREDICT COUNT(transactions.*, 0, 30, days)
FOR EACH customers.customer_id

With an anchor time of 2025-10-01 00:00:00, events at that exact time are part of the known context. The target window is left-open and right-closed (anchor excluded, end included): (2025-10-01 00:00:00, 2025-10-31 00:00:00].

Assign meaningful timestamps

• For an event table (where each row records a discrete occurrence), use the time at which the event occurred or its information became available.
• For an entity table (where each row represents a persistent object such as a customer or product), use the entity creation time when it is known.
• Do not designate an administrative modification timestamp unless it represents when the row became valid for modeling.
• Tables without a meaningful timeline can remain without a time column.

Refer to Column Preprocessing for column configuration.

Prevent data leakage

Data leakage occurs when model inputs contain information that is not available at the same prediction boundary in production.

Common causes include:

• A feature directly or indirectly contains the future target.
• An event timestamp marks the beginning of a period while another column summarizes what happened by the end of that period.
• A supposedly static entity column is overwritten over time, making its historical value unavailable.
• Training and holdout periods overlap or are ordered incorrectly.

Correct the source timeline or remove the leaking field. Do not rely on model tuning to compensate for temporally invalid data.

Detect possible leakage

Unexpectedly strong evaluation results, a large difference between offline and production performance, or one column dominating explanations can indicate leakage.

Use column statistics, evaluation results, and Explainability to identify suspicious fields. Then confirm when each value becomes available relative to the anchor time.

Set anchor time for batch predictions

You can provide an anchor time when configuring a batch prediction. If you omit it, Kumo uses the latest timestamp in the predictive query target table. Refer to Batch Predictions.

Handle date-only event data

A date such as 2025-10-01 is interpreted at the start of that day. If the intended target includes all events on October 1, choose a boundary immediately before that day. For example, use 2025-09-30 23:59:59 rather than midnight on October 1.

Also refer to time zone handling when source systems use different zones.