Not Future Check Examples

The situation: Orders are written by several regional services. An order timestamp ahead of the present moment means one of those services is converting time zones in the wrong direction, and every report that buckets orders by day will place those orders in tomorrow.

Check configuration

Payload

{
    "description": "The order timestamp can never be in the future.",
    "rule": "notFuture",
    "fields": ["ordered_at"],
    "container_id": 145,
    "coverage": 1,
    "filter": null,
    "properties": {},
    "tags": ["timeliness", "plausibility"],
    "additional_metadata": {"jira": "DATA-10400"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data (evaluated during a Scan run on 11 March 2026)

What gets flagged

O-002 carries a timestamp more than a day ahead of the Scan: the APAC service added the offset instead of subtracting it. O-003 has no timestamp and passes without firing an anomaly. Coverage is 100%, so the failing row is reported as a Record Anomaly.

Flowchart

graph TD
    A["No filter, evaluate all rows"] --> B["Read ordered_at"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is ordered_at earlier than now?"}
    E -->|Yes| D
    E -->|No| F["Flag row.<br/>Record Anomaly per failing row."]

Equivalent SQL

-- Rows the Not Future check would flag.
SELECT o.*
FROM orders o
WHERE o.ordered_at IS NOT NULL
  AND o.ordered_at >= current_timestamp();

The situation: Support agents type the incident date by hand. A mistyped year puts the incident decades ahead and pushes it out of every reporting window. Draft tickets are excluded with a filter, because agents fill the date in only when the ticket is submitted.

Check configuration

Payload

{
    "description": "A submitted incident date can never be in the future.",
    "rule": "notFuture",
    "fields": ["incident_date"],
    "container_id": 512,
    "coverage": 1,
    "filter": "status <> 'draft'",
    "properties": {},
    "tags": ["manual-entry", "plausibility"],
    "additional_metadata": {"jira": "DATA-10422"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 47
}

Sample Data (filtered to status <> 'draft', evaluated on 11 March 2026)

Why the filter matters

The filter runs before the comparison, so draft tickets, where the agent has not entered a date yet, are never evaluated and cannot inflate the violation count.

What gets flagged

T-02 was typed as 2062 instead of 2026, a transposed digit that puts the incident 36 years ahead. Coverage is 100%, so the failure is reported as a Record Anomaly, and the message ends with the filter that scoped the evaluation.

Flowchart

graph TD
    A["Apply filter: status <> 'draft'"] --> B["Read incident_date"]
    B --> C{"Is incident_date earlier than now?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: status <> 'draft']"]

Equivalent SQL

-- Rows the check would flag.
SELECT t.*
FROM tickets t
WHERE t.status <> 'draft'
  AND t.incident_date IS NOT NULL
  AND t.incident_date > current_date();

The situation: Field devices stamp their own readings. A handful run on clocks that drift ahead until the next sync, so a small share of readings legitimately arrives slightly in the future while a firmware fix rolls out. Coverage is lowered to 97% so the check tracks the problem without failing every Scan.

Check configuration

Payload

{
    "description": "Sensor readings must not be stamped in the future.",
    "rule": "notFuture",
    "fields": ["reading_at"],
    "container_id": 733,
    "coverage": 0.97,
    "filter": null,
    "properties": {},
    "tags": ["iot", "clock-drift"],
    "additional_metadata": {"jira": "DATA-10441"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 41
}

Sample Data (evaluated during a Scan run at 10:00 on 11 March 2026)

What gets flagged

dev-0088 and dev-0102 are running hours ahead of real time and have not synced yet. R-04 reported no timestamp, so it passes but still counts in the scanned total. Only 50% of the rows pass, well below the 97% coverage threshold, so the check reports a single Shape Anomaly for the dataset with a sample of the offending rows. Coverage below 100% does not produce Record Anomalies.

Flowchart

graph TD
    A["No filter, evaluate all rows"] --> B["Read reading_at"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is reading_at earlier than now?"}
    E -->|Yes| D
    E -->|No| F["Flag row.<br/>Passing rate falls below the 97%<br/>coverage, so one Shape Anomaly is reported."]

Equivalent SQL

-- Rows the check would flag.
SELECT r.*
FROM readings r
WHERE r.reading_at IS NOT NULL
  AND r.reading_at >= current_timestamp();