Anomaly Examples¶

The situation: Your stg_orders staging table is truncated and reloaded from the source system every night, and it has no incremental field or last-modified date. The same 127 bad rows come back on every load. Without duplicate handling, every nightly Scan opens 127 new anomalies, and the team acknowledges the same issues over and over.

What Qualytics reports

On the first night, the Scan opens one Record anomaly per failing row. On the next night, the rows are the same and so are their values, so each new Record anomaly has the same fingerprint as one already open.

How to triage

1. In the Scan's Anomaly Options, turn on Archive Duplicate Anomalies. From the next Scan on, a new anomaly that matches an open one is archived as Duplicate right away, so the open list keeps only the first 127.
2. Turn on Reactivate Recurring Anomalies too. When a row the team already archived as Resolved comes back, the original anomaly reopens with its history, tags, and assignees, instead of a new one starting from nothing.
3. Keep the Maximum Record Anomalies per Check high enough for the rows you want to see one by one. Above the limit, each check's failures are reported as one Shape anomaly, which has no fingerprint on this table and is never marked Duplicate.

The result: The open list holds each real issue once. Nightly Scans add a new anomaly only for a row that is new or changed.

See Scan Settings for where the options are.

The situation: Profile created an AI Managed Max Value check on discount_pct in your orders table, because every discount it saw was at most 30. During a seasonal sale, discounts of 45 are expected, and the Scan flags them.

Sample Data

What Qualytics reports

Two Record anomalies, one per order, each with the AI badge, because the only failed check is AI Managed.

How to triage

1. Open the anomaly and read the source record: the campaign explains the value.
2. Archive both anomalies as Invalid, with a comment naming the campaign. Invalid tells Qualytics the check raised a false alarm, so it trusts the check less.
3. If the higher limit is now the rule, edit the check's maximum. The check becomes an Authored check that Profile no longer changes. See AI Managed Checks Introduction.

The result: The decision is on record, and the check either learns from it or is replaced by the rule the business actually follows.

The situation: An upstream release renames total_amount to order_total in your orders table. An Expected Schema check on the table declares total_amount.

What Qualytics reports

One Shape anomaly from the Expected Schema check, reading The required field [total_amount] is not present. It has no source records, because the problem is the table's structure, not a row. A check that tests the table as a whole is rated High when it fails, so the anomaly sorts near the top of the list.

How to triage

1. Assign the anomaly to the pipeline's owner, or rely on the default assignee set on the check.
2. Create a Jira ticket from the anomaly, so the fix is tracked in the team's backlog. The ticket comes already filled in with the anomaly's details.
3. Acknowledge the anomaly, so the team sees it is being handled.
4. With Anomaly status sync on and the ticket's done status mapped to Resolved, closing the ticket after the fix archives the anomaly as Resolved on its own, once every linked ticket agrees.

The result: The break is fixed in the team's own tool, and the anomaly's Timeline shows the whole story, including the ticket.

See Anomaly Tickets.

The situation: A Not Null check on email in your contacts table, at 100% coverage, flags every contact without an email. Marketing agrees that a few missing emails are acceptable, as long as at least 95% of contacts have one.

Sample Data

What Qualytics reports

One Record anomaly per contact with no email, or, above the Maximum Record Anomalies per Check, one Shape anomaly for the whole check.

How to triage

1. Archive the existing anomalies as Discarded, with a comment that the business accepts the gap.
2. Change the check's coverage to 95%. From then on, the check fails only when fewer than 95% of contacts have an email, and it reports that as one Shape anomaly, such as email has no value in 14 of 200 asserted records.

The result: The anomaly list shows a missing email only when it becomes a real problem for the business.

See Shape Anomalies.