Less Than Check Examples

The situation: The API gateway logs a response_ms per request. The service level objective is a response strictly under 500 ms, so exactly 500 already breaks the budget and Inclusive is off.

Check configuration

Payload

{
    "description": "Response time must be under the 500 ms budget.",
    "rule": "lessThan",
    "fields": ["response_ms"],
    "container_id": 145,
    "coverage": 1,
    "filter": null,
    "properties": {"value": 500, "inclusive": false},
    "tags": ["performance", "sla"],
    "additional_metadata": {"jira": "DATA-8501"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data

What gets flagged

Request R-002 took exactly 500 ms. With Inclusive off the comparison is < 500, so the row fails. R-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 response_ms"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is response_ms < 500?"}
    E -->|Yes| D
    E -->|No| F["Flag row.<br/>Record Anomaly per failing row."]

Equivalent SQL

-- Rows the Less Than check would flag.
SELECT r.*
FROM api_requests r
WHERE r.response_ms IS NOT NULL
  AND r.response_ms >= 500;

The situation: Promotional orders may carry a discount rate of at most 0.5. Exactly 0.5 is allowed, so Inclusive is on. Regular orders use a different policy and are out of scope.

Check configuration

Payload

{
    "description": "Promotional discount rate must be at most 0.5.",
    "rule": "lessThan",
    "fields": ["discount_rate"],
    "container_id": 512,
    "coverage": 1,
    "filter": "order_type = 'promo'",
    "properties": {"value": 0.5, "inclusive": true},
    "tags": ["pricing", "range"],
    "additional_metadata": {"jira": "DATA-8544"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 29
}

Sample Data (filtered to order_type = 'promo')

Why the filter matters

The filter runs before the comparison, so regular orders are never tested against the promotional cap. Only promotional rows are evaluated.

What gets flagged

P-02 exceeds the cap. P-03 sits exactly on it and passes, because Inclusive is on. 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: order_type = 'promo'"] --> B["Read discount_rate"]
    B --> C{"Is discount_rate <= 0.5?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: order_type = 'promo']"]

Equivalent SQL

-- Rows the check would flag among promotional orders.
SELECT o.*
FROM orders o
WHERE o.order_type = 'promo'
  AND o.discount_rate IS NOT NULL
  AND o.discount_rate > 0.5;

The situation: A computed utilization_ratio must stay at or below 1, but the division accumulates floating-point error, so values land a hair above 1 without anything being wrong. An absolute tolerance of 0.0001 absorbs that. A pipeline fix is rolling out, so the check tolerates up to 0.5% failures.

Check configuration

Payload

{
    "description": "Utilization ratio must be at most 1, within floating-point tolerance.",
    "rule": "lessThan",
    "fields": ["utilization_ratio"],
    "container_id": 733,
    "coverage": 0.995,
    "filter": null,
    "properties": {"value": 1, "inclusive": true, "numeric_comparator": {"epsilon": 0.0001, "as_absolute": true}},
    "tags": ["capacity", "plausibility"],
    "additional_metadata": {"jira": "DATA-8588"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 47
}

Sample Data

What gets flagged

RS-02 is barely above 1 and falls inside the 0.0001 tolerance, so it passes. RS-03 and RS-04 exceed the cap 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 utilization_ratio"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Apply the 0.0001 tolerance"]
    E --> F{"Is the adjusted value <= 1?"}
    F -->|Yes| D
    F -->|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.0001 tolerance.
SELECT r.*
FROM resource_usage r
WHERE r.utilization_ratio IS NOT NULL
  AND (r.utilization_ratio - 0.0001) > 1;