Min Value Check Examples
Three real-world scenarios that show how the Min Value check is typically used in production: rejecting zero-value orders, enforcing a minimum billable duration with a filter, and catching implausible sensor readings. The first two run at 100% coverage and report Record Anomalies; the third lowers coverage and reports a Shape Anomaly instead.
The situation: Every order in the orders table must carry a total above zero. Rows with 0 come from a checkout bug that saves the order before the cart is priced, and they distort revenue reporting.
Check configuration
| Field | Value |
|---|---|
| Rule | Min Value |
| Field | o_totalprice |
| Filter | (none) |
| Custom Anomaly Description | Off |
| Value | 0 |
| Coverage | 100% |
| Owner | (check creator) |
| Anomaly Assignee | (Checkout Engineering) |
| Description | Order total must be greater than zero. |
| Tags | orders, range |
| Additional Metadata | jira: DATA-8101 |
| Status | Active |
Payload
{
"description": "Order total must be greater than zero.",
"rule": "minValue",
"fields": ["o_totalprice"],
"container_id": 145,
"coverage": 1,
"filter": null,
"properties": {"value": 0},
"tags": ["orders", "range"],
"additional_metadata": {"jira": "DATA-8101"},
"anomaly_message_field": null,
"template_id": null,
"status": "Active",
"owner_id": 7,
"default_anomaly_assignee_id": 12
}
Sample Data
| o_orderkey | o_totalprice | o_orderstatus |
|---|---|---|
| 1 | 1840.50 | F |
| 2 | 0 | O |
| 3 | 220.00 | F |
| 4 | (null) | O |
What gets flagged
Order 2 holds exactly 0, and the floor is exclusive, so it is flagged. Order 4 is NULL and passes without firing an anomaly. Coverage is 100%, so the failing row is reported as a Record Anomaly.
Record Anomaly
The field 'o_totalprice' has value 0, which is below the minimum value of 0.000
Flowchart
graph TD
A["No filter, evaluate all rows"] --> B["Read o_totalprice"]
B --> C{"Is value NULL?"}
C -->|Yes| D["Row passes"]
C -->|No| E{"Is o_totalprice > 0?"}
E -->|Yes| D
E -->|No| F["Flag row.<br/>Record Anomaly per failing row."]
Equivalent SQL
The situation: Support sessions marked as billable must last more than 5 minutes. Non-billable sessions can be any length and are out of scope for this check.
Check configuration
| Field | Value |
|---|---|
| Rule | Min Value |
| Field | duration_minutes |
| Filter | billable = true |
| Custom Anomaly Description | Off |
| Value | 5 |
| Coverage | 100% |
| Owner | (check creator) |
| Anomaly Assignee | (Support Operations) |
| Description | Billable sessions must last more than 5 minutes. |
| Tags | support, billing |
| Additional Metadata | jira: DATA-8144 |
| Status | Active |
Payload
{
"description": "Billable sessions must last more than 5 minutes.",
"rule": "minValue",
"fields": ["duration_minutes"],
"container_id": 512,
"coverage": 1,
"filter": "billable = true",
"properties": {"value": 5},
"tags": ["support", "billing"],
"additional_metadata": {"jira": "DATA-8144"},
"anomaly_message_field": null,
"template_id": null,
"status": "Active",
"owner_id": 7,
"default_anomaly_assignee_id": 29
}
Sample Data (filtered to billable = true)
| session_id | billable | duration_minutes |
|---|---|---|
| S-01 | true | 32 |
| S-02 | true | 5 |
| S-03 | true | 18 |
Why the filter matters
The filter runs before the comparison, so non-billable sessions are never tested against the minimum. Only billable rows are evaluated.
What gets flagged
S-02 lasted exactly 5 minutes, and the floor is exclusive, so it does not qualify as billable. Coverage is 100%, so the failure is reported as a Record Anomaly, and the message ends with the filter that scoped the evaluation.
Record Anomaly
The field 'duration_minutes' has value 5, which is below the minimum value of 5.000 [filter: billable = true]
Flowchart
graph TD
A["Apply filter: billable = true"] --> B["Read duration_minutes"]
B --> C{"Is duration_minutes > 5?"}
C -->|Yes| D["Row passes"]
C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: billable = true]"]
Equivalent SQL
The situation: A pressure sensor cannot physically report a value at or below zero. A faulty unit is producing a few such readings while it is being replaced, so the check tolerates up to 0.5% failures.
Check configuration
| Field | Value |
|---|---|
| Rule | Min Value |
| Field | pressure_kpa |
| Filter | (none) |
| Custom Anomaly Description | Off |
| Value | 0 |
| Coverage | 99.5% |
| Owner | (check creator) |
| Anomaly Assignee | (Fleet Telemetry) |
| Description | Pressure readings must be greater than zero. |
| Tags | telemetry, plausibility |
| Additional Metadata | jira: DATA-8188 |
| Status | Active |
Payload
{
"description": "Pressure readings must be greater than zero.",
"rule": "minValue",
"fields": ["pressure_kpa"],
"container_id": 733,
"coverage": 0.995,
"filter": null,
"properties": {"value": 0},
"tags": ["telemetry", "plausibility"],
"additional_metadata": {"jira": "DATA-8188"},
"anomaly_message_field": null,
"template_id": null,
"status": "Active",
"owner_id": 7,
"default_anomaly_assignee_id": 52
}
Sample Data
| reading_id | pressure_kpa | sensor_id |
|---|---|---|
| R-01 | 101.3 | S-12 |
| R-02 | 0 | S-19 |
| R-03 | -15.2 | S-19 |
| R-04 | (null) | S-27 |
What gets flagged
Readings R-02 and R-03 come from the same faulty unit: one reports zero, the other a negative value, and both fail the exclusive floor. R-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.
Shape Anomaly
For the field 'pressure_kpa', 50.000% of 4 records (2) are below the minimum value of 0.000
Flowchart
graph TD
A["No filter, evaluate all rows"] --> B["Read pressure_kpa"]
B --> C{"Is value NULL?"}
C -->|Yes| D["Row passes"]
C -->|No| E{"Is pressure_kpa > 0?"}
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
See Also
-
How It Works
The complete reference: definition, field scope, the floor property, NULL handling, nested array fields, filter behavior, and coverage.
-
Anomaly Reporting
The anomaly messages the check produces, what the numbers mean, Source Records highlighting, and Custom Anomaly Description.
-
Best Practices
Guidelines for choosing the floor, pairing rules, and keeping the signal clean.
-
Permissions
The team permission each action needs: view, create, edit, archive, restore, and delete.