How a Check Works¶

This page follows a check from its definition to the result of a Scan: what it is made of, who creates it, how Qualytics generates AI Managed checks, how a Scan evaluates it, how a failure becomes an anomaly, and how its status changes over time. Everything here applies to every rule type. Each rule type's own How It Works page covers what is specific to it.

What a Check Is Made Of¶

A check applies a rule type to a table or a file. The check form groups its settings into the same sections for every rule type:

Section	What it holds
Target	The rule type, the table or file, the fields the rule applies to, and an optional filter clause that limits the records evaluated.
Properties	The values specific to the rule type, such as the minimum on a Min Value check or the pattern on a Matches Pattern check. Some rule types have none.
Pass Criteria	The coverage: the percentage of evaluated records that must satisfy the rule for the check to pass.
Impact	Optional impact metrics that measure how big a failure is. Only rule types that flag individual records offer them.
Ownership	The owner who is responsible for the check, and an optional anomaly assignee.
Metadata	The description, tags, and additional key-value metadata.

Not every rule type uses every setting. Rules that evaluate the table as a whole, for example, have no coverage. Each rule type's Create a Check page lists the exact fields, and Getting Started with Checks links to all of them. For the steps that are the same for every rule type, see Create a Check.

Who Creates a Check¶

Every check is either Authored or AI Managed:

An Authored check is written by your team, in the check form, through the API, from a check template, or with AgentQ. Automation never changes it. See Authored Checks.
An AI Managed check is generated by Qualytics from observed data, during a Profile operation or, for Volumetric and Freshness, from Observability measurements. Later runs can update or remove it. See AI Managed Checks Introduction.

Editing how an AI Managed check evaluates data converts it to Authored. Nothing converts an Authored check back.

How AI Managed Checks Are Generated¶

AI Managed checks give a table broad starting coverage without writing every rule by hand. Your team then adds Authored checks for the policies, exceptions, and business relationships that observed data cannot show on its own. AI Managed Volumetric and Freshness checks come from Observability measurements. Every other AI Managed check comes from a Profile operation, which:

Reads the tables and files in its scope.
Calculates field statistics, such as minimum and maximum values, averages, distinct counts, distribution shape, and completeness.
Proposes candidate checks from those observations, and validates each one against the profiled data before creating it.

The Profile settings control the process. AI Effort sets how broadly Qualytics explores patterns and rule types, or turns check generation off. Oversight decides whether new checks are created as Active or as Draft for your team to review. Run Profile as often as the source changes, so the statistics and the checks stay current. See Profile Operation for every setting.

What Later Profile Runs Change¶

Each later Profile run keeps its AI Managed checks up to date:

When the data still supports a rule, its AI Managed check stays as it is.
When the data no longer supports it, the check is removed during that run.
When someone edits how the check evaluates data, it becomes Authored, and Profile leaves it alone from then on.

Profile never changes or removes an Authored check.

How to Recognize an AI Managed Check¶

AI Managed checks appear in the same check lists as Authored checks:

In the list, each one shows a purple AI badge . Hovering it shows "Authored by AI and is continuously tuned to your observed data."
On the check's page, the Summary shows the owner with the label AI Managed. A new AI Managed check is owned by Qualytics until someone transfers it.

To see only one kind, filter the list by check type. See Filter and Sort Checks.

When to keep an AI Managed check

Review the important checks against the business purpose of the data. When an AI Managed check matches that expectation, keep it managed so Profile keeps tuning it. When the rule needs a documented exception or business-specific logic, edit it or add an Authored check.

How a Scan Evaluates a Check¶

A Scan evaluates every Active check on the tables and files in its scope. For each check:

Apply the filter clause. When the check has one, only the records that match it are evaluated. The rest cannot fail the check.
Apply the rule. Each record is tested against the rule type and its properties. Rules that look at the data as a whole, such as a Unique or a Volumetric check, test the table or file instead of single records.
Apply the coverage. At 100% coverage, any failing record fails the check. Below 100%, the check fails only when the share of passing records drops below the coverage.
Record the result. Each check ends the Scan with one of three results:

Result	Meaning
Passed	The check was evaluated and produced no anomaly.
Failed	The check was evaluated and produced at least one anomaly.
Not Asserted	The check could not be evaluated, for example because of an invalid filter or a field that no longer exists. It produced no anomaly, but it did not pass either. The other checks on the table still run.

See Scan Outcomes for how these results roll up into the Scan's own result.

From Failure to Anomaly¶

Every failure becomes an anomaly, and the Scan decides which type:

A record that fails a record-level check becomes a Record anomaly.
A failure that concerns the data as a whole, such as a missing field or a duplicate under a Unique check, becomes a Shape anomaly.
When a check fails more records than the Scan's Maximum Record Anomalies per Check (10 by default), its failures are reported as one Shape anomaly that keeps the total count.

How much each anomaly matters depends on the check's Importance and, when it has them, its Impact Metrics. See How Anomalies Work for what happens next.

Check Status¶

A check is always in one of these states:

Status	What it means
Active	Evaluated by every Scan of its table or file. Its failures produce anomalies.
Draft	Saved but not evaluated. A Draft waits for someone with the Author team permission to review and activate it.
Archived	Retired from Scans and kept for reference. A check is archived either as Discarded, when it no longer fits the business rules, or as Invalid, when it was wrong. A later Profile run can create an AI Managed check again after a Discarded one, but not after an Invalid one.

An archived check can be restored as Draft or Active, or deleted permanently. See the Status how-tos, starting with Draft Checks.

Testing a Check Before a Scan¶

Two tools show what a check will do before a Scan relies on it:

Validate, in the check form, tests the check against its data before you save it, and refuses a configuration that cannot run.
Dry Run evaluates a saved check against a sample of its data and shows the anomalies it would produce, without creating any. See Dry Run.