Required Values Check Examples

The situation: Orders carry one of five priority labels, and the operations dashboard has a lane for each. A load that drops a priority entirely leaves an empty lane, which reads as "no urgent orders today" rather than "the data is incomplete".

Check configuration

Payload

{
    "description": "Every order priority must be represented in the orders table.",
    "rule": "requiredValues",
    "fields": ["o_orderpriority"],
    "container_id": 145,
    "filter": null,
    "properties": {
        "list": ["1-URGENT", "2-HIGH", "3-MEDIUM", "4-LOW", "5-NOT URGENT"]
    },
    "tags": ["reference-data", "completeness"],
    "additional_metadata": {"jira": "DATA-10600"},
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data

What gets flagged

The loaded rows hold three of the five required priorities. 4-LOW and 5-NOT URGENT never appear, so the check reports them as missing. No individual row is wrong, which is why the anomaly is raised against the column and carries no source records.

Flowchart

graph TD
    A["Collect the values in o_orderpriority"] --> B{"Does every required<br/>value appear at least once?"}
    B -->|Yes| C["Check passes"]
    B -->|No| D["Shape Anomaly naming<br/>the values that never appeared"]

Equivalent SQL

-- The required values that never appear in the column.
SELECT v.required_value
FROM (VALUES ('1-URGENT'), ('2-HIGH'), ('3-MEDIUM'), ('4-LOW'), ('5-NOT URGENT'))
     AS v(required_value)
WHERE v.required_value NOT IN (
    SELECT DISTINCT o_orderpriority FROM orders
);

The situation: Sales land from four regions every day. When one region's feed breaks, the rows simply stop, and totals look plausible because the other three still report. Scoping the check to the current day turns a silent gap into an alert on the morning it happens.

Check configuration

Payload

{
    "description": "Every region must report sales each day.",
    "rule": "requiredValues",
    "fields": ["region_code"],
    "container_id": 512,
    "filter": "sale_date = current_date()",
    "properties": {
        "list": ["EMEA", "NAMER", "LATAM", "APAC"]
    },
    "tags": ["completeness", "daily-feed"],
    "additional_metadata": {"jira": "DATA-10617"},
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 47
}

Sample Data (filtered to sale_date = current_date())

Why the filter matters

Here the filter is the point of the check. Without it, APAC would pass on the strength of yesterday's rows and the broken feed would go unnoticed. Scoping to the current day requires each region to report today.

What gets flagged

Three regions reported and APAC did not: its feed failed overnight. Because the filter narrows where a required value may appear, the absence is caught on the day it happens rather than whenever someone notices the totals look low. The message names the field and the missing region; it does not repeat the filter, so the description is where the daily scope has to be stated.

Flowchart

graph TD
    A["Apply filter: sale_date = current_date()"] --> B["Collect the values in region_code"]
    B --> C{"Does every region<br/>appear at least once today?"}
    C -->|Yes| D["Check passes"]
    C -->|No| E["Shape Anomaly naming<br/>the missing region"]

Equivalent SQL

-- The regions that did not report today.
SELECT v.region_code
FROM (VALUES ('EMEA'), ('NAMER'), ('LATAM'), ('APAC')) AS v(region_code)
WHERE v.region_code NOT IN (
    SELECT DISTINCT region_code
    FROM sales
    WHERE sale_date = current_date()
);

The situation: A migration rewrote a ticket status column to a new vocabulary. Every status in the new set must be represented, otherwise part of the mapping was never applied and those tickets are sitting under an old label the application no longer understands.

Check configuration

Payload

{
    "description": "Every status in the new vocabulary must be present after the migration.",
    "rule": "requiredValues",
    "fields": ["status"],
    "container_id": 733,
    "filter": null,
    "properties": {
        "list": ["open", "in_progress", "blocked", "resolved", "closed"]
    },
    "tags": ["migration", "completeness"],
    "additional_metadata": {"jira": "DATA-10634"},
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 41
}

Sample Data

What gets flagged

Four of the five statuses appear. blocked never does, because the migration mapping had no rule for the old on_hold label and those tickets kept it. The rule reports the missing status; pairing it with an Expected Values check would additionally report the leftover on_hold rows, which is the other half of the same problem.

Flowchart

graph TD
    A["Collect the values in status"] --> B{"Does every status in the<br/>new vocabulary appear?"}
    B -->|Yes| C["Check passes"]
    B -->|No| D["Shape Anomaly naming<br/>the missing status"]

Equivalent SQL

-- The statuses from the new vocabulary that never appear.
SELECT v.status
FROM (VALUES ('open'), ('in_progress'), ('blocked'), ('resolved'), ('closed'))
     AS v(status)
WHERE v.status NOT IN (SELECT DISTINCT status FROM tickets);