Greater Than Field Check Examples

The situation: An order cannot ship before it was placed. Rows where ship_date precedes order_date come from a backfill that wrote both dates from different sources. Same-day shipping is normal, so equal dates must pass and Inclusive is on.

Check configuration

Payload

{
    "description": "Ship date must be later than the order date.",
    "rule": "greaterThanField",
    "fields": ["ship_date"],
    "container_id": 145,
    "coverage": 1,
    "filter": null,
    "properties": {"field_name": "order_date", "inclusive": true},
    "tags": ["orders", "integrity"],
    "additional_metadata": {"jira": "DATA-8801"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data

What gets flagged

Order O-002 ships two days before it was placed. O-003 ships the same day and passes, because Inclusive is on. O-004 has no ship date yet, so there is nothing to compare and the row passes. Coverage is 100%, so the failing row is reported as a Record Anomaly.

Flowchart

graph TD
    A["No filter, evaluate all rows"] --> B["Read ship_date and order_date"]
    B --> C{"Is either value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is ship_date >= order_date?"}
    E -->|Yes| D
    E -->|No| G["Flag row.<br/>Record Anomaly per failing row."]

Equivalent SQL

-- Rows the Greater Than Field check would flag.
SELECT o.*
FROM orders o
WHERE o.ship_date IS NOT NULL
  AND o.order_date IS NOT NULL
  AND o.ship_date < o.order_date;

The situation: Products on sale must still list above their cost, otherwise every unit sold loses money. Discontinued products are cleared below cost on purpose and are excluded with a filter. Selling exactly at cost is not acceptable, so Inclusive is off.

Check configuration

Payload

{
    "description": "Active products must list above their unit cost.",
    "rule": "greaterThanField",
    "fields": ["list_price"],
    "container_id": 512,
    "coverage": 1,
    "filter": "status = 'active'",
    "properties": {"field_name": "unit_cost", "inclusive": false},
    "tags": ["pricing", "integrity"],
    "additional_metadata": {"jira": "DATA-8844"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 29
}

Sample Data (filtered to status = 'active')

Why the filter matters

The filter runs before the comparison, so discontinued products, which are cleared below cost on purpose, are never evaluated.

What gets flagged

SKU-02 lists exactly at cost. With Inclusive off the comparison is strict, so the row fails. 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 = 'active'"] --> B["Read list_price and unit_cost"]
    B --> C{"Is either value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is list_price > unit_cost?"}
    E -->|Yes| D
    E -->|No| F["Flag row.<br/>Anomaly message ends with<br/>[filter: status = 'active']"]

Equivalent SQL

-- Rows the check would flag among active products.
SELECT p.*
FROM products p
WHERE p.status = 'active'
  AND p.list_price IS NOT NULL
  AND p.unit_cost IS NOT NULL
  AND p.list_price <= p.unit_cost;

The situation: The settled amount must be at least the invoiced amount, but the two are computed by different systems and differ by cents from rounding. A relative tolerance of 0.1% absorbs that noise. A reconciliation cleanup is in progress, so the check tolerates up to 0.5% failures.

Check configuration

Payload

{
    "description": "Settled amount must cover the invoiced amount, within rounding tolerance.",
    "rule": "greaterThanField",
    "fields": ["settled_amount"],
    "container_id": 733,
    "coverage": 0.995,
    "filter": null,
    "properties": {"field_name": "invoiced_amount", "inclusive": true, "numeric_comparator": {"epsilon": 0.001, "as_absolute": false}},
    "tags": ["finance", "reconciliation"],
    "additional_metadata": {"jira": "DATA-8888"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 47
}

Sample Data

What gets flagged

S-02 is one cent short but falls inside the 0.1% tolerance, so it passes. S-03 and S-04 fall short by far more than the margin and fail. 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["Read settled_amount and invoiced_amount"]
    B --> C{"Is either value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is settled_amount, plus the 0.1%<br/>tolerance, >= invoiced_amount?"}
    E -->|Yes| D
    E -->|No| G["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, allowing a 0.1% tolerance.
SELECT s.*
FROM settlements s
WHERE s.settled_amount IS NOT NULL
  AND s.invoiced_amount IS NOT NULL
  AND (s.settled_amount + abs(s.settled_amount) * 0.001) < s.invoiced_amount;