Before Date Time Check Examples

The situation: A patient registry rejects records where date_of_birth falls on or after the day the record was created, which happens when a data-entry form defaults the field to today. The registry enforces an upper boundary of 2026-01-01 00:00 UTC, the start of the current intake year, because no patient in the historical load can be born on or after it.

Check configuration

Payload

{
    "description": "Birth dates must be earlier than the current intake year.",
    "rule": "beforeDateTime",
    "fields": ["date_of_birth"],
    "container_id": 412,
    "coverage": 1,
    "filter": null,
    "properties": {
        "datetime": "2026-01-01T00:00:00Z"
    },
    "tags": ["registry", "plausibility"],
    "additional_metadata": {"jira": "DATA-5120"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 31
}

Sample Data

What gets flagged

Patient P-014 carries a date_of_birth of 2026-03-02, which is later than the boundary and therefore implausible for the historical load. Coverage is 100%, so the failing row is reported as a Record Anomaly.

Flowchart

graph TD
    A["No filter, evaluate all rows"] --> B["Interpret date_of_birth as timestamp"]
    B --> C{"Is date_of_birth <<br/>2026-01-01T00:00:00Z?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Flag row.<br/>Record Anomaly per failing row."]

Equivalent SQL

-- Rows the Before Date Time check would flag.
SELECT p.*
FROM patients p
WHERE p.date_of_birth IS NOT NULL
  AND p.date_of_birth >= TIMESTAMP '2026-01-01 00:00:00 UTC';

The situation: Once a month closes, no new entry may be posted into it. The journal_entries table keeps a posted_at timestamp, and every entry belonging to the March period must have been posted before the close date, 2026-04-05 23:59 UTC. Entries from other periods are out of scope for this check.

Check configuration

Payload

{
    "description": "Entries in the March period must be posted before the period close.",
    "rule": "beforeDateTime",
    "fields": ["posted_at"],
    "container_id": 517,
    "coverage": 1,
    "filter": "period = '2026-03'",
    "properties": {
        "datetime": "2026-04-05T23:59:00Z"
    },
    "tags": ["finance", "period-close"],
    "additional_metadata": {"jira": "DATA-5211"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 44
}

Sample Data (filtered to period = '2026-03')

Why the filter matters

The filter runs before the comparison, so entries in other periods are never tested against the March close date. Only rows in the March period are evaluated.

What gets flagged

JE-1002 was posted on 2026-04-07 09:15:00, after the period close, so it is the only row reported. 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: period = '2026-03'"] --> B["Interpret posted_at as timestamp"]
    B --> C{"Is posted_at <<br/>2026-04-05T23:59:00Z?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: period = '2026-03']"]

Equivalent SQL

-- Rows the check would flag in the March period.
SELECT j.*
FROM journal_entries j
WHERE j.period = '2026-03'
  AND j.posted_at IS NOT NULL
  AND j.posted_at >= TIMESTAMP '2026-04-05 23:59:00 UTC';

The situation: An archive table holds orders that were closed before the platform migration on 1998-01-01 00:00 UTC. Anything dated on or after that boundary belongs in the live system, not in the archive. Some rows carry a NULL o_orderdate from a legacy import and are tolerated.

Check configuration

Payload

{
    "description": "Archived orders must have an order date earlier than the migration cutoff.",
    "rule": "beforeDateTime",
    "fields": ["o_orderdate"],
    "container_id": 318,
    "coverage": 0.995,
    "filter": null,
    "properties": {
        "datetime": "1998-01-01T00:00:00Z"
    },
    "tags": ["archive", "historical"],
    "additional_metadata": {"jira": "DATA-5307"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 24
}

Sample Data

What gets flagged

Rows 1 and 3 fail because their o_orderdate is later than the cutoff, so they do not belong in the archive. Row 4 is NULL, so it passes without firing an anomaly but still counts in the scanned total. Only 50% of the rows pass, which is below the 99.5% 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["Interpret o_orderdate as timestamp"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is o_orderdate <<br/>1998-01-01T00:00:00Z?"}
    E -->|Yes| D
    E -->|No| F["Flag row.<br/>Passing rate falls below the 99.5%<br/>coverage, so one Shape Anomaly is reported."]

Equivalent SQL

-- Rows the check would flag.
SELECT o.*
FROM orders_archive o
WHERE o.o_orderdate IS NOT NULL
  AND o.o_orderdate >= TIMESTAMP '1998-01-01 00:00:00 UTC';