Check Examples¶

Reviewing check 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 and the API · owner_id field notes.

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.

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¶

For the full conversion rules, see Introduction. For the screen-by-screen edit walkthrough, see Edit an AI Managed Check.

See Also¶