Max Value Check Examples

The situation: The orders table stores the applied discount as a percentage in discount_pct. Anything above 100 means the pricing engine wrote a raw amount into a percentage column, which produces negative revenue downstream. Exactly 100 is a legitimate full discount.

Check configuration

Payload

{
    "description": "Discount percentage must not exceed 100.",
    "rule": "maxValue",
    "fields": ["discount_pct"],
    "container_id": 145,
    "coverage": 1,
    "filter": null,
    "properties": {"value": 100},
    "tags": ["pricing", "range"],
    "additional_metadata": {"jira": "DATA-8001"},
    "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 holds 2500, an amount written into a percentage column. O-003 is exactly 100 and passes, because the ceiling is inclusive. O-004 is NULL 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 discount_pct"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is discount_pct <= 100?"}
    E -->|Yes| D
    E -->|No| F["Flag row.<br/>Record Anomaly per failing row."]

Equivalent SQL

-- Rows the Max Value check would flag.
SELECT o.*
FROM orders o
WHERE o.discount_pct IS NOT NULL
  AND o.discount_pct > 100;

The situation: Standard-tier accounts may not carry a credit limit above 50,000; higher tiers have their own ceilings and are out of scope for this check.

Check configuration

Payload

{
    "description": "Standard-tier credit limit must not exceed 50,000.",
    "rule": "maxValue",
    "fields": ["credit_limit"],
    "container_id": 640,
    "coverage": 1,
    "filter": "tier = 'standard'",
    "properties": {"value": 50000},
    "tags": ["risk", "range"],
    "additional_metadata": {"jira": "DATA-8044"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 26
}

Sample Data (filtered to tier = 'standard')

Why the filter matters

The filter runs before the comparison, so enterprise accounts are never tested against the standard ceiling. Only standard-tier rows are evaluated.

What gets flagged

A-4002 carries a limit above the standard ceiling, probably a tier change that was never applied to the account record. A-4003 sits exactly on the ceiling and passes. 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: tier = 'standard'"] --> B["Read credit_limit"]
    B --> C{"Is credit_limit <= 50000?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: tier = 'standard']"]

Equivalent SQL

-- Rows the check would flag on the standard tier.
SELECT a.*
FROM accounts a
WHERE a.tier = 'standard'
  AND a.credit_limit IS NOT NULL
  AND a.credit_limit > 50000;

The situation: A warehouse feed writes line quantities into quantity. No single line can legitimately exceed 10,000 units. A faulty integration is producing a few oversized rows while it is being fixed, so the check tolerates up to 0.5% failures.

Check configuration

Payload

{
    "description": "Line quantity must not exceed 10,000 units.",
    "rule": "maxValue",
    "fields": ["quantity"],
    "container_id": 733,
    "coverage": 0.995,
    "filter": null,
    "properties": {"value": 10000},
    "tags": ["inventory", "plausibility"],
    "additional_metadata": {"jira": "DATA-8090"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 52
}

Sample Data

What gets flagged

Lines L-02 and L-03 come from the faulty integration and exceed the ceiling. L-04 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["Read quantity"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is quantity <= 10000?"}
    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 l.*
FROM order_lines l
WHERE l.quantity IS NOT NULL
  AND l.quantity > 10000;