How Metric Checks Work¶

Definition¶

Records the value of the selected field during each Scan and asserts that it stays within a range, or changes by no more than a set amount or percentage since the previous Scan.

Overview¶

The Metric rule follows one number over time: a total, a rate, or a balance that lives in a single row. Each Scan reads that row, records the field's value as a measurement, and compares it with your limits, either as an absolute value or as a change from the last measurement.

Because the check follows one value, the rows it evaluates must resolve to exactly one row. The usual sources are a Computed Table that aggregates a KPI into one row, or a summary table narrowed to one row by the filter clause.

Typical use cases:

Alert when yesterday's revenue total moves by more than 30% from the previous day's.
Keep a conversion rate for one region between a floor and a ceiling.
Catch an account balance that jumps by more than an expected amount between Scans.

Field Scope¶

Single: The rule evaluates one numeric field.

Accepted Types

Type	Supported
`Integral`
`Fractional`

Anomaly Types¶

Type	Supported
Record Flag inconsistencies at the row level
Shape Flag inconsistencies in the overall patterns and distributions of a field

When the Check Is Evaluated¶

A Metric check is evaluated by a Scan that includes the Data Integrity check category. See Select Check Categories. Only Active checks are evaluated, and every evaluation records a measurement, whether the check passes or fails.

Metric measurements come from Scans only. A Profile does not record them, and Volume Tracking and Freshness Tracking have no effect on the check. The measurements appear on the check's card in the Metrics tab of Observability.

Exactly One Row¶

The Scan applies the filter clause to the rows it reads, then expects exactly one row to remain:

One row: the field's value on that row is the measurement, and the check is asserted.
No rows, or more than one: the check is recorded as Not Asserted, with a message that it resolved to that many rows instead of the expected 1. No measurement is recorded and no anomaly is created.
One row with an empty value: the check is also Not Asserted, because there is no number to measure.

The rows that count are the rows the Scan reads. A Full Scan reads the whole container. An Incremental Scan reads only the rows that are new or changed since the previous one, so a summary row that did not change can leave nothing to evaluate. See Incremental and Full Scans below.

Properties¶

Property	What it sets
Comparison	How the value is evaluated: Absolute Value, Absolute Change, or Percentage Change. See Comparisons.
Min Value	The lower limit. The value itself for Absolute Value, or the smallest allowed movement from the previous measurement for the change comparisons (a negative value allows a decrease of that much).
Max Value	The upper limit, with the same meaning as Min for each comparison.

At least one of Min Value and Max Value is required, and Min cannot be greater than Max. Both limits are inclusive. For Percentage Change, the form labels them Min Percentage and Max Percentage and takes the values in percent (enter 20 for 20%).

The Previous Measurement¶

Absolute Change and Percentage Change compare the value with the most recent measurement of the check. Absolute Value needs no history.

The first Scan of a change comparison has no previous measurement, so it only records the value and passes. From the second Scan on, the value is compared with the one before it.

Incremental and Full Scans Keep Separate Histories¶

The previous measurement is taken from an earlier Scan of the same read strategy. An Incremental Scan compares with the last Incremental Scan, and a Full Scan with the last Full Scan. The two never mix, because an Incremental Scan reads only part of the container and its value can differ from a Full Scan's. A check that runs under both strategies therefore has two baselines, and the first Scan of each strategy only records.

The Field and Comparison Are Locked After the First Scan¶

The field and the comparison can be changed only while the check has never been part of a Scan, since every measurement belongs to that field and comparison. Once a Scan has included the check, the limits and the filter can still change, but saving a different field or comparison is rejected. To switch, create a new check and archive the old one.

One Active Check per Field, Filter, and Comparison¶

A container can hold only one Active Metric check for each combination of field, filter clause, and comparison. Creating or activating a second one is rejected with a message that an existing check conflicts, whatever its limits. A different filter (for example, another region) or another comparison on the same field is allowed. Draft and archived checks never conflict.

Always Authored¶

Qualytics never creates Metric checks automatically: there is no AI Managed version of this rule, and every Metric check is one you author. The limits stay exactly as you set them.

The Filter Clause¶

The filter clause is a SQL WHERE expression applied before the evaluation. For a Metric check it usually does one job: narrowing a summary table to the single row the check follows, such as region = 'EMEA'. Rows outside the filter are ignored entirely.

When a filter is set, the message names it at the end of its first sentence, as (applied to records where <expression>). Record and Shape Anomaly messages both carry it.

Coverage¶

The rule does not use coverage: it evaluates one row, so there is no share of passing rows to tolerate. The form shows no Coverage slider, and the API rejects a coverage other than 1 with 422.