> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/sdgm/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/sdgm/_mcp/server.

# Anchor Time and Data Leakage

> Use temporal boundaries correctly when training and running AutoML models

> **Prerelease documentation**
>
> This Kumo Studio information is prerelease and is not yet supported. Stay tuned for the Docker and Kubernetes releases.

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:

**`PQL`**

```text PQL
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](/kumo-engine/1.0.0/kumo-studio-guide-coming-soon/preliminary-documentation/connect-data/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](/kumo-engine/1.0.0/kumo-studio-guide-coming-soon/preliminary-documentation/train-model/evaluation/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](/kumo-engine/1.0.0/kumo-studio-guide-coming-soon/preliminary-documentation/run-models/batch-prediction).

## 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](/faq/kumo-engine/time-data-leakage/how-does-kumo-handle-timezones-for-timestamp-values) when source systems use different zones.