How Not Future Checks Work

Definition

Asserts that the field is a date or timestamp not later than the present moment.

Overview

The Not Future rule compares a date or timestamp against the moment the check runs. Any value ahead of that moment is reported.

Because the reference is the current time rather than a value you configure, the rule needs no properties: it is the whole rule. That also means it never goes stale, which is the reason to prefer it over a fixed upper bound for fields that record events that already took place.

Typical use cases:

Catch order, payment, or event timestamps written ahead of the clock.
Detect a time zone applied in the wrong direction during ingestion.
Flag manually entered dates typed with the wrong year.

Field Scope

Single: The rule evaluates one field per check. It accepts Date and Timestamp fields, and Array fields whose elements are dates or timestamps.

Accepted Types

Type	Supported
`Date`
`Timestamp`
`Array`

Anomaly Types

Type	Supported
Record Flag inconsistencies at the row level
Shape Flag inconsistencies in the overall patterns and distributions of a field

Evaluation Flow

Every Not Future check follows the same four-step evaluation flow:

Apply the filter clause. If the check has a filter set, only rows matching the filter expression continue to the next step. Rows outside the filter are ignored and cannot contribute to the violation count.
Read the field on the row. The platform reads the date or timestamp being evaluated.
Compare it against the present moment. The row passes when the value is earlier than the moment the check evaluates it. A value ahead of that moment fails. On an array field, every element is tested and the row passes only when all of them are in the past.
Apply coverage. At 100% coverage, any failing row causes the check to fail. Below 100% coverage, the check fails only when the passing fraction drops below the threshold (see Coverage and Tolerance).

"Now" Is the Moment of Evaluation, Not a Fixed Date

The reference is the current time when the Scan evaluates the row, so the boundary moves with every run. A record that passes today because its timestamp is an hour old passed yesterday too, and will keep passing.

This is what makes the rule maintenance-free, and also what makes it unsuitable for a fixed cut-off. If you need "not later than the end of the fiscal year", use Before Date Time with an explicit boundary.

Time Zones Decide What Counts as the Future

Both sides of the comparison are evaluated in UTC. A timestamp stored without a zone, or converted in the wrong direction during ingestion, can land hours ahead of the real moment and be reported even though the underlying event is in the past.

When a check fires on values only slightly ahead of now, the cause is almost always a zone conversion or a clock difference between the system that wrote the row and the one evaluating it, not a genuinely future event.

Array Fields Are Tested Element by Element

On an Array field, every element must be in the past for the row to pass. One future element fails the whole row, and an empty array passes because there is nothing ahead of now inside it.

Elements that are empty are skipped rather than reported, the same way a NULL value is on a scalar field.

The element-wise form runs as a field-level check, so an array field always reports a Shape Anomaly rather than one anomaly per row, at any coverage.

NULL Handling

The check passes NULL values: a row with an empty date is not counted as a violation. Not Future only constrains dates that are present.

If the field must also be populated, pair it with a Not Null check on the same field.

The Filter Clause

The filter clause is a SQL WHERE expression applied before the evaluation. Filtered-out rows are ignored entirely (they cannot trigger a violation and are not counted in the totals).

When a filter is set, both the Record Anomaly and the Shape Anomaly messages end with [filter: <expression>] so the evaluated scope is visible in the alert.

Coverage and Tolerance

Coverage is a fractional value between 0 and 1 that defines the minimum fraction of evaluated rows that must pass:

1.0 (100%, default): every row in the filtered set must pass. Any failing row causes the check to fail. This is the strictest setting.
< 1.0: the check tolerates a fraction of rows failing. The check fails only when the fraction of passing rows drops below the threshold.

Lower coverage values are useful when a small, known fraction of failures is expected. Use coverage carefully: a 0.5% tolerance can mask a real regression that happens to fall just under the threshold.