Anomalies Introduction¶

Learning what anomalies are

An anomaly is how Qualytics tells you that data did not meet what a check expects. Each time a Scan evaluates your checks, every failure it finds is recorded as an anomaly: the row, the field, or the table involved, the checks that failed, and the evidence behind them. Anomalies are where data quality work starts. Someone reads them, decides whether the problem is real, and records what was done about it.

This Deep Dive explains the concepts behind anomalies. It starts with what an anomaly is and why it matters, then gives a short tour of each topic, from how anomalies are created and the two anomaly types to how they are ranked, tracked, and recognized when they come back. Each topic has its own page with the full details.

What an Anomaly Is¶

An anomaly keeps the evidence behind a failure in one place:

• The checks that failed, each with its failure message. One anomaly can group several checks, for example when a single row breaks more than one rule, unless One anomaly per check is turned on for its table or file.
• The data involved: the row, the field, or the table or file, and when the datastore stores them, the rows behind the failure.
• Its context: the Scan that found it, when it was found, and where the data lives.
• Its triage: its status, Impact, tags, assignees, linked tickets, and every change and comment since it was found.

An anomaly is evidence of a potential issue, not proof that the data is wrong. It reflects only the checks that were active and the data the Scan read. A value can fail a check and still be correct for the business, and a real problem can go unnoticed when no check covers it. That is why every anomaly is reviewed by someone who knows the data before it is closed.

Why Anomalies Matter¶

Anomalies turn check failures into work a team can track. Each one has assignees, a status, and a history, so nothing a Scan finds is lost or reviewed twice.

Use anomalies to:

• See what needs attention first: Every anomaly list is sorted by Impact, so the anomalies that matter most come first.
• Give each issue an owner: Assign the people responsible, who are then notified when someone else changes the anomaly.
• Record the decision: Archive an anomaly as Resolved, Invalid, Duplicate, or Discarded, with a comment that says why.
• Avoid repeat work: Recognize an issue the team has already seen, instead of opening it again on every Scan.
• Work where the team already works: Link an anomaly to a Jira or ServiceNow ticket, or start a Flow when one is found.

The Deep Dive at a Glance¶

How Anomalies Are Created¶

A Scan evaluates every active check in its scope, and each failure becomes an anomaly. The checks come from two places: AI Managed checks, which Qualytics creates from patterns it observes in the data, and Authored checks, which your team writes for business rules. A new anomaly starts with the tags of its check, the default assignee of every check that has one, and a description built from the failures. Flows and assignment notifications then tell the right people about it. See How Anomalies Work.

AI Managed and Authored Anomalies¶

An anomaly from AI Managed checks says the data broke a pattern it used to follow, and one from Authored checks says it broke a rule the business set. When every failed check is AI Managed, the anomaly shows an AI badge. The resolution you archive it with also tunes those checks: Resolved makes Qualytics trust them more, Invalid less. See AI Managed and Authored Anomalies.

Record and Shape Anomalies¶

Every anomaly is one of two types. A Record anomaly flags one row that failed one or more checks, such as a missing value or a value out of range, and shows that row with the failing cell highlighted. A Shape anomaly describes a problem across many rows or the whole dataset, such as a missing field, duplicate keys, or a check that failed too many rows to report one by one. See Record Anomalies and Shape Anomalies.

Impact¶

Impact ranks how much an anomaly matters: Low, Medium, High, or Critical. Each failed check is rated by how much failed, such as the share of checked records that failed, and that rating is raised or lowered by the check's Importance. The anomaly takes the highest level among its failed checks. Anomaly lists are sorted by it, and Flows can act only on anomalies at the level you choose. See Anomaly Impact.

Status¶

Status says where an anomaly stands. An open anomaly is Active, when nobody has looked at it yet, or Acknowledged, when someone is working on it. An archived anomaly is closed with a resolution: Resolved, Duplicate, Invalid, or Discarded. An archived anomaly is read only until it is restored, and it comes back as Acknowledged. See Anomaly Status.

Assignees¶

Assignees are the people responsible for an anomaly. A new anomaly starts with the default assignee of each check that failed, and anyone with the Author team permission can change them. Assignees are notified each time someone else changes the anomaly. See Anomaly Assignees.

Fingerprints¶

A fingerprint is an identifier built from the checks that failed and the data involved, so a later Scan can tell when it finds the same issue again. With duplicate handling on, the Scan archives the repeat as a duplicate, or reopens the earlier anomaly if it was already closed, instead of opening a new one every time. See Anomaly Fingerprints.

Anomaly Views and Details¶

Anomalies are shown on four screens: the anomaly lists, where you find and prioritize them, the anomaly page, where you investigate one in depth, the side panel, where you triage many in a row, and the anomalies panel, which opens from a Scan, a check, or the Lineage graph. See Anomaly Views. Each part of an anomaly has a page of its own:

• Description: the plain-language explanation of the issue, which the team can rewrite.
• Source Records: the rows behind the anomaly, and how masked values are protected.
• Tickets: the Jira and ServiceNow tickets that carry the anomaly into the team's queue.
• Timeline: every change made to the anomaly, and the team's comments.

Putting It into Practice¶

Examples follow anomalies through real triage scenarios, Best Practices gather guidelines for keeping the anomaly list short and trusted, and Permissions lists who can do what.

What You Will Find Here¶