Quality Check Ownership Examples

Real-world scenarios that show how check ownership is typically used in production. Each example 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. The engineer opens the datastore's Quality 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 they review, they open the Edit Check form and change the Owner to themselves. The inline warning "Once transferred, ownership cannot be returned to Qualytics" appears in the dropdown.
3. After saving, the Owner filter is updated to their own user (via the Owned subtab) so they can 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.

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 Explore > Checks, applies the Owner filter, and picks the leaving engineer's name. The list narrows to every check they currently own.
2. The team lead selects all the checks via the row checkboxes. The selection toolbar shows the total count.
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 History 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 History, 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 How It Works · 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 History 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.