Predicted By Check Examples

The situation: Line discounts are generated as 8% of the extended price, with small rounding differences from the pricing service. A discount more than 2 away from that figure means the rate was applied to the wrong base or overridden by hand, and the invoice total will be wrong.

Check configuration

Payload

{
    "description": "The discount must stay within 2 of 8% of the extended price.",
    "rule": "predictedBy",
    "fields": ["l_discount"],
    "container_id": 145,
    "coverage": 1,
    "filter": null,
    "properties": {
        "expression": "l_extendedprice * 0.08",
        "tolerance": 2
    },
    "tags": ["business-logic", "pricing"],
    "additional_metadata": {"jira": "DATA-10800"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data

What gets flagged

The prediction for every row here is 8. Line 3 sits one away and passes, inside the band of 2. Line 2 is four above and line 4 is five below, both outside it. The band is symmetric, so a discount that is too small fails exactly like one that is too large. Coverage is 100%, so each failing row is reported as its own Record Anomaly.

Flowchart

graph TD
    A["Read the row"] --> B["Evaluate l_extendedprice * 0.08"]
    B --> C{"Is the difference from<br/>l_discount at most 2?"}
    C -->|Yes| D["Row passes"]
    C -->|No, or returns nothing| E["Flag row and quote the<br/>expression and tolerance"]

Equivalent SQL

-- Rows the Predicted By check would flag.
SELECT l.*
FROM lineitem l
WHERE NOT (abs((l.l_extendedprice * 0.08) - l.l_discount) <= 2)
   OR l.l_extendedprice IS NULL
   OR l.l_discount IS NULL;

The situation: A demand planning table stores both the forecast units and the units actually shipped for each product and week. The planning team accepts a gap of up to 50 units; beyond that the forecast model needs review. Weeks that have not closed yet are excluded, because their actuals are still accumulating.

Check configuration

Payload

{
    "description": "Actual units must land within 50 of the forecast for a closed week.",
    "rule": "predictedBy",
    "fields": ["actual_units"],
    "container_id": 512,
    "coverage": 1,
    "filter": "week_status = 'closed'",
    "properties": {
        "expression": "forecast_units",
        "tolerance": 50
    },
    "tags": ["forecasting", "planning"],
    "additional_metadata": {"jira": "DATA-10822"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 47
}

Sample Data (filtered to week_status = 'closed')

Why the filter matters

The filter runs before the comparison, so weeks that are still accumulating actuals are never evaluated. Without it, every open week would look like a forecast miss simply because the week is not over.

What gets flagged

P-101 shipped 610 units above forecast, far outside the 50-unit band, so the model under-predicted that product badly. The other two land within 35 and 20 of their forecasts and pass. 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: week_status = 'closed'"] --> B["Evaluate forecast_units"]
    B --> C{"Is the difference from<br/>actual_units at most 50?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: week_status = 'closed']"]

Equivalent SQL

-- Rows the check would flag.
SELECT d.*
FROM demand_plan d
WHERE d.week_status = 'closed'
  AND NOT (abs(d.forecast_units - d.actual_units) <= 50);

The situation: A reporting table stores a daily revenue figure alongside the sum the transactional system reported. The two are computed by different pipelines and should agree within 100 currency units. A migration is rewriting part of the history, so a small share is expected to disagree while it runs, and coverage is lowered to 95%.

Check configuration

Payload

{
    "description": "Reported revenue must track the source figure within 100.",
    "rule": "predictedBy",
    "fields": ["reported_revenue"],
    "container_id": 733,
    "coverage": 0.95,
    "filter": null,
    "properties": {
        "expression": "source_revenue",
        "tolerance": 100
    },
    "tags": ["reconciliation", "migration"],
    "additional_metadata": {"jira": "DATA-10841"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 41
}

Sample Data

What gets flagged

The 9th and 10th are thousands away from the source figure, well outside the 100-unit band: the migration reprocessed those two days with an incomplete set of transactions. The other two agree within 55 and 40. Only 50% of the rows pass, below the 95% 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["Read the row"] --> B["Evaluate source_revenue"]
    B --> C{"Is the difference from<br/>reported_revenue at most 100?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Count the row as failing"]
    D --> F{"Passing fraction<br/>at or above 95%?"}
    E --> F
    F -->|Yes| G["Check passes"]
    F -->|No| H["Shape Anomaly for the dataset"]

Equivalent SQL

-- Rows the check would flag.
SELECT r.*
FROM revenue_report r
WHERE NOT (abs(r.source_revenue - r.reported_revenue) <= 100);