# Check Examples

Source: https://userguide.qualytics.io/data-quality-checks/checks/deep-dive/examples/

Real-world scenarios that show how the concepts shared by every check play out in practice. For examples of a specific rule type, see the **Examples** page of its section under **Rule Types**.

## Ownership

Real-world scenarios that show how check ownership is typically used. Each one combines the same building blocks: defaults at creation, transfer modes, filtering, and notifications.

### Onboarding a new data engineer

**Context.** A new data engineer joins the team and is added to the **Customer Data** datastore with the **Drafter** team permission. They will gradually take over a set of AI Managed checks that have been running since the datastore was profiled, all still owned by the `Qualytics` user.

**What happens.**

1. Their team lead, who has the **Author** team permission on the datastore, opens the datastore's **Checks** tab and applies the **Owner** filter, picking `Qualytics` from the top of the dropdown. The list narrows to every AI Managed check that no one has taken over.
2. For each check the engineer should take over, the lead opens the **Edit Check** form and changes the **Owner** to the engineer. The inline warning **"Once transferred, ownership cannot be returned to Qualytics"** appears in the dropdown.
3. The engineer then filters by their own user (via the **Owned** subtab) to keep a personal queue of the checks they are now responsible for.

**Why it works.** AI Managed checks default to `Qualytics`, so they are easy to find by filter. The explicit transfer requires only the **Drafter** permission on the datastore for the new owner, which the engineer already has, and the **Author** permission for the user making the change, which is why the lead makes it. A Drafter cannot open the Edit Check form on an Active check.

### Reassigning a teammate's checks

**Context.** An engineer is rotating off the team. Their Authored checks on the **Orders** datastore need to move to a new owner before they lose access.

**What happens.**

1. The team lead opens the **Orders** datastore's **Checks** tab, applies the **Owner** filter, and picks the leaving engineer's name. The list narrows to every check they currently own. Bulk selection is available on a datastore's **Checks** tab, not in **Explore > Checks**.
2. The team lead hovers a check card and selects **Select all in page**. The selection toolbar shows the total count. The selection covers only the current page, so if the list spans several pages, the lead repeats steps 2 to 4 on each one.
3. They open the **bulk menu**  in the toolbar and click **Edit** . The **Bulk Edit Checks** modal opens; they toggle on the **Owner** row and pick the new owner from the dropdown.
4. After **Save**, every check is updated to the new owner. Each check's **Timeline** records the bulk change with the lead's name as the user who made it.
5. The new owner sees the checks under their **Owned** subtab on the next page load.

**Why it works.** The **Owner** filter scopes the list to a single user before bulk selection, eliminating the risk of accidentally reassigning unrelated checks. The bulk endpoint replaces (not merges) the owner, which is the intended behavior in a handoff.

### Coordinating edits with ownership notifications

**Context.** Two engineers maintain a shared set of checks on the **Inventory** datastore. They want to know when the other person edits one of their checks so they can keep their downstream dashboards in sync.

**What happens.**

1. Each check is owned by one of the two engineers; ownership was assigned explicitly when the checks were authored.
2. When engineer A edits the **coverage** of a check owned by engineer B, the platform creates an **Ownership** in-app notification for engineer B: *"Engineer A updated a check you own"* (`#482` • Volumetrics).
3. Engineer B opens the notification, sees the change in the check's **Timeline**, and updates their dashboard query the same day.

**Why it works.** The notification fires whenever the updater is not the owner, so every cross-edit produces a signal. Self-edits stay silent, which keeps the notification feed focused on edits the owner did not make.

### Auditing AI Managed checks before a compliance review

**Context.** Ahead of a quarterly compliance review, the data platform team needs a clean inventory of which checks are still managed by `Qualytics` (and therefore subject to Profile refreshes) versus those that have been explicitly taken over.

**What happens.**

1. A team admin opens **Explore > Checks** and sets the **Owner** filter to `Qualytics`. The list shows every check still managed by `Qualytics` across all datastores they have access to.
2. They export the list (or call `GET /api/quality-checks?owner_id=<qualytics_user_id>`) and share it with the compliance reviewer.
3. The reviewer flags the subset that should be locked from Profile refreshes. For each flagged check, the admin opens the **Edit Check** form, transfers ownership to a named user, and saves. If any assertion property is also edited during the same save, the check converts to Authored; ownership transfer alone (no assertion changes) keeps `inferred: true` while attributing responsibility to a human owner.

**Why it works.** The `Qualytics` user is treated like any other owner in the filter dropdown, so the audit becomes a single filter operation. The transfer-only path (without editing assertion properties) is the Explicit transfer flow documented in [Check Ownership · Explicit transfer](https://userguide.qualytics.io/data-quality-checks/checks/deep-dive/ownership/#explicit-transfer-edit-form-or-bulk-update) and the [API · `owner_id` field notes](https://userguide.qualytics.io/data-quality-checks/checks/api/#the-owner_id-field).

### Draft promotion with automatic owner reassignment

**Context.** A Drafter-level reviewer creates a quality check as a Draft for review by a senior engineer. The senior engineer holds the **Author** team permission; the Drafter does not.

**What happens.**

1. The Drafter authors the check and saves it as **Draft**. They are recorded as the owner because they created it.
2. The senior engineer opens the check, validates it, and flips the **Status** from **Draft** to **Active**.
3. Because the Drafter cannot manage an Active check, the **Drafter activation transfer** fires automatically: the owner is reassigned from the Drafter to the senior engineer at the same save.
4. The check's **Timeline** records both events on the same timeline entry: the status change *and* the ownership reassignment.

**Why it works.** Drafter activation transfer prevents an Active check from being stuck with an owner who cannot edit it. The pattern keeps the audit trail accurate: the senior engineer ends up as the responsible owner the moment the check goes live.

## AI Managed

AI Managed checks provide broad starting coverage from observed data behavior. Your team supplies the business judgment: choose the right oversight setting, review controls that protect important decisions, document known exceptions, and add Authored checks for expectations that statistics cannot establish.

The scenarios below show when to keep an AI Managed check, when to take ownership of it, and when to add a separate business rule.

### Scenario 1: Review a Baseline Rule

**Context.** You run Profile on an `orders` table. Qualytics creates a **Not Null** check for `order_id` with **Coverage = 100%** because every profiled record contains an identifier.

**What happens.** A data steward confirms that every order must have an identifier. If Oversight kept the new check in Draft, the steward activates it. Later Profile runs continue to maintain it as an AI Managed check.

**Why it works.** The observed pattern and the business expectation agree. Keeping the check AI Managed lets Profile maintain the baseline without removing human review from an important control.

| Field | Value |
| --- | --- |
| Rule | Not Null |
| Field | `order_id` |
| Coverage | 100% |
| Owner | **AI Managed** |

### Scenario 2: Account for a Documented Exception

**Context.** Qualytics creates a **Matches Pattern** check for `phone` with **Coverage = 100%**. Your team knows that a small set of records still uses a legacy format during a planned migration.

**What happens.** After confirming the accepted exception with the data owner, you lower **Coverage** to the approved percentage and document the reason in the description or metadata. Saving the evaluation change converts the check to **Authored**.

**Why it works.** The Authored check preserves a deliberate business decision. Future Profile runs will not replace the approved coverage setting.

### Scenario 3: Correct Rule Logic

**Context.** An AI Managed **Max Length** check for `product_sku` uses a limit of 12 characters. The product team confirms that a new, valid SKU format can contain up to 16 characters.

**What happens.** You edit the rule property from 12 to 16, document the new format, and save. The check converts to **Authored** because its evaluation logic changed.

**Why it works.** Observed history could not predict the approved format change. A person supplies the new business requirement, and conversion ensures that later Profile runs preserve it.

### Scenario 4: Let a Behavioral Baseline Adapt

**Context.** An AI Managed **Volumetric** check monitors the daily row count for a `transactions` table. As scheduled observability measurements accumulate, Qualytics adjusts the expected bounds after normal seasonal growth.

**What happens.** The data owner reviews the updated bounds and compares them with expected business activity. If they still represent normal behavior, the check remains AI Managed. If a one-time event should not redefine the baseline, the owner edits the properties and documents the exception, converting the check to Authored.

**Why it works.** Measurement history can adapt the observed baseline, while a person decides whether the change reflects normal business behavior.

### Scenario 5: Add a Narrower Business Rule

**Context.** An AI Managed **Max Value** check confirms that `discount_pct` never exceeds 100 across an `orders` table. Partner sales have a separate policy that caps discounts at 25.

**What happens.** Clone the AI Managed check: open it with **Edit**, then choose **Clone** from the **⋮** menu at the top of the dialog. In the clone, add a filter such as `sales_channel = 'partner'`, change the maximum value to `25`, and validate the draft. The clone is an independent Authored check, while the original AI Managed check continues to cover the table-wide pattern.

**Why it works.** The observed baseline remains useful, and the Authored check captures business context for a narrower group of records.

### Scenario 6: Govern a Large Set of Checks

**Context.** A Profile operation creates many AI Managed checks across a large datastore. Reviewing every check with the same depth would hide the controls that matter most.

**What happens.** Your team uses a risk-based review:

1. Keep new checks in Draft when the datastore requires approval before activation.
2. Start with data used for critical decisions, regulatory reporting, customer-facing processes, or automated actions.
3. Review checks with active anomalies or unexpected changes on the Timeline.
4. Activate AI Managed checks that match the intended use of the data.
5. Edit or replace checks that need business-specific logic, and add Authored checks for missing expectations.

**Why it works.** AI supplies scalable starting coverage, while people concentrate governance effort where an incorrect control or missed issue would have the greatest impact.

### Quick Reference: When to Step In

| If you see... | Do this... | Result |
| --- | --- | --- |
| An AI Managed rule that matches the business expectation | Keep it AI Managed, or activate it after review if it is Draft | Profile can continue to maintain it |
| A small, approved exception | Change **Coverage** and document the reason | Converts to Authored and preserves the exception |
| Rule logic that does not match a known requirement | Edit **Properties** | Converts to Authored and preserves the correction |
| A need for a narrower or stricter variation | **Clone** (from the **⋮** menu in the Edit dialog), then edit the clone | The AI Managed baseline and Authored variation coexist |
| A critical control awaiting approval | Keep it **Draft** until the responsible steward reviews it | Prevents activation before governance review |
| A rule that should not apply to the data | Archive it as **Invalid** and document why | Records feedback and removes it from active use |

For the full conversion rules, see [Introduction](https://userguide.qualytics.io/data-quality-checks/checks/deep-dive/ai-managed-checks/). For the screen-by-screen edit walkthrough, see [Edit an AI Managed Check](https://userguide.qualytics.io/data-quality-checks/checks/how-tos/managing/edit-checks/).

## See Also

- **Check Permissions**

  Which team permissions can view, create, edit, archive, and delete checks, change owners, and edit AI Managed checks.

  [Check Permissions](https://userguide.qualytics.io/data-quality-checks/checks/deep-dive/permissions/)
- **How a Check Works**

  What a check is made of, who creates it, how AI Managed checks are generated, how a Scan evaluates it, and how its status changes.

  [How a Check Works](https://userguide.qualytics.io/data-quality-checks/checks/deep-dive/how-it-works/)
- **Authored Checks**

  What an Authored check is, who governs it, and how it differs from an AI Managed check.

  [Authored Checks](https://userguide.qualytics.io/data-quality-checks/checks/deep-dive/authored-checks/)
- **AI Managed Checks**

  What an AI Managed check is, which edits convert it to Authored, and how to go back.

  [AI Managed Checks](https://userguide.qualytics.io/data-quality-checks/checks/deep-dive/ai-managed-checks/)
- **Check Ownership**

  Who is responsible for a check, the four ways ownership changes, notifications, and filtering by owner.

  [Check Ownership](https://userguide.qualytics.io/data-quality-checks/checks/deep-dive/ownership/)
- **Check Importance**

  How much a check's failures matter, and how its tags raise or lower it.

  [Check Importance](https://userguide.qualytics.io/data-quality-checks/checks/deep-dive/importance/)
- **Impact Metrics**

  Numbers measured over a check's failed records that show how big a failure is.

  [Impact Metrics](https://userguide.qualytics.io/data-quality-checks/checks/deep-dive/impact-metrics/)
- **Dry Run**

  What a Dry Run evaluates and how to read its results, anomalies, and source records.

  [Dry Run](https://userguide.qualytics.io/data-quality-checks/checks/deep-dive/dry-run/)
- **Check Views**

  The check lists, the check page, and the side panel: how to reach each one, what it shows, and what you can do there.

  [Check Views](https://userguide.qualytics.io/data-quality-checks/checks/deep-dive/check-details/check-views/)
- **Check Anomalies**

  The anomalies a check has produced, and how to triage them from the check's page.

  [Check Anomalies](https://userguide.qualytics.io/data-quality-checks/checks/deep-dive/check-details/anomalies/)
- **Check Timeline**

  The change log of a check, its past versions, and the comments your team leaves on it.

  [Check Timeline](https://userguide.qualytics.io/data-quality-checks/checks/deep-dive/check-details/timeline/)

*Last updated: November 10, 2026.*