Positive Check Examples
Three real-world scenarios that show how the Positive check is typically used in production: guarding order quantities, validating billable amounts with a filter, and auditing a legacy measure mid-cleanup. The first two run at 100% coverage and report Record Anomalies; the third lowers coverage and reports a Shape Anomaly instead.
The situation: Every line in the order_lines table must carry a quantity above zero. Rows with 0 come from a cart bug that saves an emptied line, and negative rows come from returns that were written into the wrong table.
Check configuration
| Field | Value |
|---|---|
| Rule | Positive |
| Field | quantity |
| Filter | (none) |
| Custom Anomaly Description | Off |
| Coverage | 100% |
| Owner | (check creator) |
| Anomaly Assignee | (Checkout Engineering) |
| Description | Order line quantity must be a positive number. |
| Tags | orders, range |
| Additional Metadata | jira: DATA-8201 |
| Status | Active |
Payload
{
"description": "Order line quantity must be a positive number.",
"rule": "positive",
"fields": ["quantity"],
"container_id": 145,
"coverage": 1,
"filter": null,
"properties": {},
"tags": ["orders", "range"],
"additional_metadata": {"jira": "DATA-8201"},
"anomaly_message_field": null,
"template_id": null,
"status": "Active",
"owner_id": 7,
"default_anomaly_assignee_id": 12
}
Sample Data
| line_id | quantity | order_id |
|---|---|---|
| L-001 | 3 | O-77 |
| L-002 | 0 | O-78 |
| L-003 | -2 | O-79 |
| L-004 | (null) | O-80 |
What gets flagged
Line L-002 holds zero and L-003 holds a negative quantity; both fail, because Positive requires values strictly above zero. L-004 is NULL and passes without firing an anomaly. Coverage is 100%, so each failing row is reported as a Record Anomaly.
Record Anomaly
The field 'quantity' has value 0, which is not a positive number
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 > 0?"}
E -->|Yes| D
E -->|No| F["Flag row.<br/>Record Anomaly per failing row."]
Equivalent SQL
The situation: Invoice lines marked as billable must carry an amount above zero. Credit lines are negative by design and live in the same table, so they are excluded with a filter.
Check configuration
| Field | Value |
|---|---|
| Rule | Positive |
| Field | amount |
| Filter | line_type = 'billable' |
| Custom Anomaly Description | Off |
| Coverage | 100% |
| Owner | (check creator) |
| Anomaly Assignee | (Billing Operations) |
| Description | Billable invoice lines must carry a positive amount. |
| Tags | billing, range |
| Additional Metadata | jira: DATA-8233 |
| Status | Active |
Payload
{
"description": "Billable invoice lines must carry a positive amount.",
"rule": "positive",
"fields": ["amount"],
"container_id": 512,
"coverage": 1,
"filter": "line_type = 'billable'",
"properties": {},
"tags": ["billing", "range"],
"additional_metadata": {"jira": "DATA-8233"},
"anomaly_message_field": null,
"template_id": null,
"status": "Active",
"owner_id": 7,
"default_anomaly_assignee_id": 29
}
Sample Data (filtered to line_type = 'billable')
| line_id | line_type | amount |
|---|---|---|
| I-01 | billable | 250.00 |
| I-02 | billable | 0.00 |
| I-03 | billable | 79.90 |
Why the filter matters
The filter runs before the comparison, so credit lines, which are negative by design, are never tested. Only billable lines are evaluated.
What gets flagged
I-02 carries a zero amount, which is not a valid billable line. 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 'amount' has value 0.00, which is not a positive number [filter: line_type = 'billable']
Flowchart
graph TD
A["Apply filter: line_type = 'billable'"] --> B["Read amount"]
B --> C{"Is amount > 0?"}
C -->|Yes| D["Row passes"]
C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: line_type = 'billable']"]
Equivalent SQL
The situation: A legacy feed writes weight_kg with occasional zeros and negatives from a broken unit conversion. A fix is rolling out, so a small fraction of bad rows is expected and the check tolerates up to 0.5% failures.
Check configuration
| Field | Value |
|---|---|
| Rule | Positive |
| Field | weight_kg |
| Filter | (none) |
| Custom Anomaly Description | Off |
| Coverage | 99.5% |
| Owner | (check creator) |
| Anomaly Assignee | (Logistics Data team) |
| Description | Shipment weight must be a positive number. |
| Tags | logistics, plausibility |
| Additional Metadata | jira: DATA-8266 |
| Status | Active |
Payload
{
"description": "Shipment weight must be a positive number.",
"rule": "positive",
"fields": ["weight_kg"],
"container_id": 733,
"coverage": 0.995,
"filter": null,
"properties": {},
"tags": ["logistics", "plausibility"],
"additional_metadata": {"jira": "DATA-8266"},
"anomaly_message_field": null,
"template_id": null,
"status": "Active",
"owner_id": 7,
"default_anomaly_assignee_id": 52
}
Sample Data
| shipment_id | weight_kg | source |
|---|---|---|
| S-01 | 12.4 | wms |
| S-02 | 0 | legacy |
| S-03 | -3.2 | legacy |
| S-04 | (null) | legacy |
What gets flagged
Shipments S-02 and S-03 come from the legacy feed with a zero and a negative weight. S-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 'weight_kg', 50.000% of 4 records (2) are not positive numbers
Flowchart
graph TD
A["No filter, evaluate all rows"] --> B["Read weight_kg"]
B --> C{"Is value NULL?"}
C -->|Yes| D["Row passes"]
C -->|No| E{"Is weight_kg > 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 comparison, NULL handling, arrays, 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 between the sign rules, pairing them, and keeping the signal clean.
-
Permissions
The team permission each action needs: view, create, edit, archive, restore, and delete.