Validations

A validation is the thing you run. It bundles the rules of one or more data assets into a single unit, runs them together, and keeps a health score for how the data is doing. You run a validation manually with Run, or automatically on a schedule. Running an asset, or a single rule, runs a validation too: the asset's default validation (see Asset and rule runs). Every run is an execution run whose outcome lands in Results and can trigger alerts.

Think of it as "the checks for one dataset, pipeline, or domain": Nightly orders might cover orders, order_items, and payments; Customer 360 might cover every table your CRM sync writes.

How a validation is built

• A validation holds rules, one by one, and it can hold rules from several assets. A run executes exactly those rules — the enabled ones. A disabled rule stays in the validation but doesn't run.
• The assets a validation covers are simply the assets its rules belong to. There is no separate asset list to maintain.
• Per asset, a validation holds All rules (auto-include new ones) or Selected rules. With All rules, every rule of the asset is in the validation and a rule added to the asset later joins it automatically. With Selected rules, only the rules you tick are in it, and a new rule joins only if its author picks this validation when creating it (see Which validations a rule is in). Taking a single rule out of an All rules asset switches that asset to Selected rules, keeping the rest.
• There's nothing to copy or re-author: a rule always belongs to its asset, so edit a rule on its asset and every validation holding it picks up the change.
• You choose the rules from either side: per asset on the validation page, or per rule on the asset's Rules tab (see Rules).
• One asset (and one rule) can be in many validations (for example, a fast hourly validation and a thorough nightly one).

Field	What it stores
Name / description	Human label and an optional summary.
Tags	Free-form catalog tags.
Rules	The rules the validation runs, from one or more assets. The assets it covers follow from them.
Health score	The share of rule checks that passed over the validation's runs in the last 30 days (0–100), shown on the validations list. "No data" when nothing ran in the window. The detail page charts the failures per run instead (see Failures on the detail page). See Health score.
Last run	When the validation last ran, even if that run produced no score (for example, the data source was unreachable).

Asset defaults: every rule lives in a validation

Every data asset that has rules has one default validation. It covers only that asset, holds every rule on it, and keeps itself up to date: a rule you add to the asset joins it straight away, and a rule you delete leaves it. It takes the asset's name and workspace. On the Validations list it carries an Asset default badge, and the data-asset page links to it as Default validation. Run it, schedule it, and alert on it like any other validation.

• You don't edit it by hand. It covers only its own asset, and its rules follow the asset. Adding or removing an asset or a single rule on a default returns 409.
• It goes with its asset. Deleting a default directly returns 409. Moving the asset to the recycle bin hides the default from the list, restoring the asset brings it back unchanged, and purging the asset deletes the default. Its past runs and results are kept: they stay on the Results page, with no validation linked.
• Existing assets got their default when the platform upgraded. If an asset already had a validation that ran just that asset, came from its old checkpoint, and had exactly the asset's name (and no team), that validation became the default, with its schedules, alerts, and history. Otherwise a new one was created, and a validation you'd named yourself stays an ordinary validation you can edit and delete.

Your own validations keep working as before. A validation that listed an asset with all of its rules before rule suites were retired still holds every rule that asset had at that point; each of those rules can now be taken out one by one. A rule added to the asset from now on joins only its asset's default validation and the validations its author picks.

Rules added one by one. Every rule a validation holds runs: a run executes every enabled rule the validation holds, however it was added. An operator can list every rule-by-rule membership in an organisation with dqc v2-reconcile --org <org-id> (see the CLI reference).

Asset and rule runs

The ▶ Run on a data asset and on a single rule both run the asset's default validation:

• Asset run — runs every enabled rule on the asset. The execution run records trigger asset.
• Rule run — runs only that rule (the run's rule_ids filter). The execution run records trigger rule.

Both work on direct and agent-mode assets; a single-rule run on an agent-mode asset sends just that rule to your on-prem Privacy Agent. Their runs appear in the default validation's Run history and count toward its health score. In the API: POST /api/v2/.../data-assets/{asset_id}/rules/run and .../rules/{rule_id}/run (see Execution runs → API).

Runs of a retired checkpoint are kept as asset-trigger execution runs of the validation the checkpoint maps to (see Checkpoints (retired)).

Choosing an asset's rules

On the validation page, each asset the validation covers shows how many of its rules the validation holds, for example 3 of 5, or all of them. Choosing an asset's rules opens a picker:

• All rules (auto-include new ones) — every rule on the asset. Rules added to the asset later join automatically.
• Selected rules — tick the rules to include. Rules added to the asset later don't join unless you pick them.

The picker says what changes before you save. The change is recorded in the audit log.

Any rule can be taken out of the validation from the Rules card (the red ✕), one at a time. Taking one out of an All rules asset switches that asset to Selected rules: its other rules stay, and new rules stop joining.

In the API, a validation carries is_default and default_for_asset_id, and the list takes ?include_defaults=false to leave defaults out (they're included by default). The data-asset GET (/api/v1/.../data-assets/{id}) returns default_validation_id. A validation's rules (GET /api/v2/.../validations/{id}/rules) and a rule's "In validations" chips carry source: default (the asset's default validation, which can't be edited), asset_list (the asset is in All rules mode there, so new rules join automatically) or explicit (picked one by one). To list the rules a validation holds, you can also use GET /api/v2/.../rules?validation_id={id} (see Rules → API).

The membership endpoints (all under /api/v2/organizations/{org}/workspaces/{ws}, writes need the can_manage_validation permission):

Endpoint	What it does
GET .../validations/{id}/assets	Each asset the validation holds rules of: mode (all when the asset is in All rules mode, else selected), the held rule_ids and asset_rule_count. member_id is always null.
PUT .../validations/{id}/assets/{asset_id}/rules	Set which of an asset's rules the validation holds: {"data": {"mode": "all"}} (every rule of the asset; later rules join automatically) or {"data": {"mode": "selected", "rule_ids": [...]}}. Set semantics: sending the same body twice changes nothing.
DELETE .../validations/{id}/assets/{asset_id}	Take the asset and all its rules out.
POST .../validations/{id}/rules	Add one rule (rule_id). Idempotent.
DELETE .../validations/{id}/rules/{rule_id}	Take one rule out.
PUT .../data-assets/{asset_id}/rules/{rule_id}/validations	Set which validations a rule is in (see Rules).

A default validation is never edited through these (409). A validation, rule or asset you can't see is a 404; a rule or asset from another workspace can't join the validation (400).

The old asset-list endpoints are a deprecated alias for one release: GET .../validations/{id}/members (and the members field of GET .../validations/{id}) returns a list derived from the validation's rules, one entry per asset they cover, with rule_suite_id: null and deprecated: true. POST .../validations/{id}/members and DELETE .../validations/{id}/members/{member_id} return 410 Gone: add or remove rules instead. The responses carry Deprecation: true and a Link header to the successor.

What a run executes

A run executes the validation's enabled rules, one pass per asset (each asset's rules are checked together, in one pass against its data):

• Some of the rules. On the validation page, Run with options (next to Run) runs some of the rules (tick them), for this run only. In the API, POST /api/v2/.../validations/{id}/run with {"data": {"rule_ids": [...]}} runs only those rules of the validation. See the API reference.
• Agent-mode assets run through the on-prem Privacy Agent. Their rules run exactly as the validation holds them, and a rule subset (rule_ids, or a single rule's Run) is honoured: the agent runs only those rules.
• An asset whose rules in the validation are all disabled runs nothing. A validation whose rules are all disabled, or whose assets are gone, is rejected with 409 instead of running nothing.

The plan is fixed when a run starts: a rule added to (or removed from) the validation while a run is going applies from the next run.

Older scoped validations. A validation set up earlier may check only part of an asset. That setting keeps working, and the validation page shows it: the asset is marked Batch-scoped, and its scope controls appear only for an asset that was set up this way. Every other asset is checked whole.

API naming. In the API a validation lives at /api/v2/.../validations, while some wire fields keep their original machine names, such as rule_group_id / rule_group_name on results. They mean the same thing.

Owning team

A validation has its own optional owning team (team_id), set when you create it or from Edit. With no team it reads Workspace-shared. The team is a label, so everyone in the workspace still sees the validation, unless a workspace admin turns on Restrict to team (team_restricted). Then the validation and its run history are visible only to that team (and admins). A restricted validation can't hold another team's rules, and a restricted asset's rules only fit a validation restricted to the same team. An asset's default validation takes its asset's team. See Team ownership.

Operations you can do

• Create / edit / delete — Validations → New validation (UI) or the POST/PATCH/DELETE /api/v2/.../validations endpoints. The New validation dialog can include assets up front — and optionally start from a rule template, which applies the template's rules to each selected asset before adding it — so a fresh validation is runnable immediately instead of an empty shell. Edit a validation's name, description, and tags from its detail page (the pencil action). Deleting a validation removes its rule memberships (the rules themselves stay on their assets) and returns 204. Past runs and results are kept: its execution runs, their results, and the per-asset result rows stay on the Results page, labelled Validation deleted where the validation name would be (the API returns them with validation_id / rule_group_id set to null). A run still in progress when you delete is marked cancelled. A validation referenced by a schedule or an alert is still deletable: a schedule that runs this validation is deleted with it, and an alert rule survives, no longer pointing at the deleted validation (its past alerts are kept).
• Generate with AI — Validations → Generate with AI drafts a validation from a description of what to check. Naming the assets is optional: without them the AI picks the relevant ones from the workspace. You review the name, the description, the assets and the rules for each before anything is saved. Create validation then creates the validation and any new rules, reuses existing rules instead of duplicating them, and adds exactly the rules you kept. See Generate a validation with AI.
• See and change the rules a run executes — the detail page's Rules card lists every rule a run of the validation executes, grouped by asset, with each rule's severity. It reads the same plan the run engine uses (GET /api/v2/.../validations/{id}/run-rules), so what it lists is what runs. Click a rule to open its asset with that rule focused, where you edit it. Add rules opens a picker over every data asset in the workspace: pick an asset, then all of its current rules or just some. An asset with no rules is shown disabled with a link to add rules on the asset first. Take a rule out with its red ✕.
• See a data asset's validations (reverse lookup) — the Data Assets list shows a Validations column: the validation(s) each asset belongs to, as chips linking to the validation. It reads one workspace-wide endpoint, GET /api/v2/.../validations/asset-memberships, which returns {"data": [{data_asset_id, rule_groups: [{group_id, group_name}]}]}, derived from the validations' rules (an asset's default validation included). Only assets with a rule in at least one validation appear; an asset in none is absent (the column reads "—"). Read-only, viewer-tier, workspace-isolated.
• See every rule running on one asset — the data-asset detail page carries a read-only Rules on this asset card that consolidates every rule reaching the asset, labelled by source: the asset's own rules, plus the validation(s) that also run them (each a chip linking to the validation). Because a validation holds the asset's own rules, being in a validation doesn't add distinct rules — the rule list is shown once with a "Runs in: …" header rather than repeated per validation; an asset in no validation reads "Own rules only". It reads GET /api/v2/.../data-assets/{asset_id}/rules/running, which returns {"data": {data_asset_id, suite_id: null, own_rules, rule_groups: [{group_id, group_name, …}]}} (suite_id is deprecated and always null). Read-only, viewer-tier, workspace-isolated.
• Run now — POST /api/v2/.../validations/{id}/run runs the validation's enabled rules, one pass per asset, and returns 202 with the run's execution_run_id and parent_result_id. Running (and stopping) needs the can_run_validation permission; creating and editing a validation needs can_manage_validation. See What a run executes for running only some of the rules. Running is read-only on your source: it reads your data and records results, changing nothing in the source. Each asset runs via its own datasource mode: a direct asset runs in the cloud worker; an agent-mode asset runs through your on-prem Privacy Agent, so a validation can freely mix direct and agent assets. Direct assets' results land as the run executes; agent assets complete asynchronously (whenever your agent next polls), so a mixed validation's rollup stays in running until the last agent asset reports back, then finalises once over the full set (its has_agent_member flag in the run response tells you some assets complete asynchronously). A validation with nothing it can run (every rule disabled, or its assets gone) is rejected (409) rather than dispatching a run that would validate nothing, and an entirely empty validation (no rules, no assets) is a 400.
• Watch and review runs — the detail page's Run history lists every run of the validation, in progress and finished, newest first, each led by its status in words (Passed, Failed, Stopped). An in-progress run opens by itself and lists every rule of every asset in the run, each with its live state: Queued until its asset starts, Running (a spinner) while its asset runs, then Passed or Failed as that asset's results land. The asset running now is highlighted and named on the run row, with a count of assets done and rules checked. The run engine checks all of an asset's rules in one pass, so an asset's rules show as running together and get their results together. The Rules card shows the same live state beside each rule while the run is going, including for a run with options: a rule the run left out reads Not in this run. Click a run to open its Validation run page. Expand a run (the chevron) for its per-rule pass/fail breakdown in place, grouped by asset: each asset links to the asset page, an icon link opens that asset's result, and each rule links to its asset with that rule focused — the way back from a failing rule to where it's defined. An in-progress run carries an icon-only Stop: the asset running now is interrupted within a few seconds (it shows Stopping until then, and records no result), and the assets still queued never start. An asset already running on your on-prem Privacy Agent can't be interrupted from the cloud, so it finishes there.
• Schedule it — the detail page's Schedule card holds this validation's schedules: Add schedule, pick a cadence, save. It runs in the organization's schedule timezone. The table reads each cadence in words ("Every day at 8:00 AM"); a cadence created through the API that has no plain-words form reads Custom cadence, with the technical detail behind its ℹ️. See Schedules.
• See when validations run — the Schedule tab of the Validations page shows a calendar of past runs (tinted passed / failed) and upcoming scheduled runs. The calendar is in the organization's schedule timezone, not your browser's: its days, "today" and every time, each labelled with the zone abbreviation. Each schedule's cron is read in the zone it fires in and placed at the matching organization time and day. Only upcoming runs are marked Scheduled; a past day shows the runs that actually happened. Daylight-saving changes follow the scheduler: a time skipped by the spring-forward change fires at the change, and a time that repeats in the fall-back hour fires twice. Custom cron schedules (created through the API) expand too — weekday and month names (0 9 * * MON-FRI), ranges, steps, and the @daily / @hourly / @weekly / @monthly / @yearly shorthands; a cron using L, W, or # shows only its next run.
• Watch and stop a run — every play (▶) button becomes a spinning stop control while its run is in flight. This covers a validation's Run on the list and detail page, a schedule's Run now, an asset's Run, and a single rule's Run. While an asset's whole rule set runs, each of its rules' buttons spins too, because the engine checks all of an asset's rules in one pass; stopping from any of them stops that run. The same goes for a validation run: while it is on an asset, that asset's Run button (on its page and its Data Assets row) and each of its rules' buttons spin. Stopping from one of those stops only that asset's part of the validation run: the asset is interrupted within a few seconds (it records no result), the validation carries on with its other assets, and the run finishes with that asset marked Cancelled. A rule's Stop does the same, because the engine checks all of an asset's rules in one pass; its tooltip says so ("Stops this asset's checks in validation name"). To stop the whole validation run, use the Stop on the validation itself (its row on the Validations list, or the detail page). The asset's buttons go back to play when the run moves on to the next asset. The state comes from the server (GET /api/v1/.../active-runs, see the API reference). So the button keeps spinning after a refresh, and when the run was started elsewhere: another page, the command palette, a schedule firing, or a teammate. Click the spinning control to stop the run, whoever started it. Stopping a run you started from that button (a single rule's run, an asset's run, a schedule's run, or a whole validation run from the validation's own Stop) interrupts the asset in progress within a few seconds (it records no result) and cancels the rest. The exception is an asset already running on your on-prem Privacy Agent: it finishes there. The button reads Stopping… until the run winds down. Runs you start, from any button or the command palette's Run validation…, get a toast when they start and when they finish. The finish toast still shows if you've moved to another page or refreshed, and it has a View results link to the run's Validation run page (the page its Run history row opens). The link is there whether the run passed, failed, errored or was stopped; a profile run has no results page, so its toast has no link. Scheduled runs and runs other people start don't toast.
• See what's running — anything in flight also reads as running, from the same server state as the buttons: a Running… pill (Stopping… once a Stop was requested) next to the validation's name on the Validations list and on its page, next to the data asset's name on the Data Assets list and its page header (Profiling… while a profile runs), and next to each rule in the asset's Rules list. Those rows are highlighted too. The top bar shows N runs in progress while anything runs in the workspace; click it for the list, each linking to the validation (for a validation run) or the data asset (for an asset, rule or profile run) where you can watch it.

Health score

A validation's health score is the share of its rule checks that passed over its runs in the last 30 days: 100 × passed checks ÷ evaluated checks. The Health (30d) column on the list shows the band (Good above 90, Fair 70–90, Poor below 70, a grey No data when nothing ran in the window) next to the health % and the failure %, for example "88% · 12% failed", plus how many runs failed when any did ("87% · 13% failed · 49/50 runs failed"). The full definition, and how it relates to the data-asset and dashboard numbers, is on the Health score page.

Failures on the detail page

The detail page doesn't lead with the health score. Its Failures card is a bar chart of how many rules failed in each run over the last 30 days, oldest on the left:

• One bar per run. When the window holds more than 30 runs, the chart shows one bar per day instead (that day's failed rule checks, summed over its runs). A day with no runs has no bar.
• A run where every rule passed is a short teal mark on the baseline, so a passing run never looks like missing data. A run that failed before checking any rule (for example, the data source was unreachable) is a short vermilion mark.
• Hover a bar for its date, its status and "3 of 12 rules failed". Click it (or Tab to it and press Enter) to open that run's Validation run page. A day's bar opens that day's latest failing run, or its latest run if none failed.
• One line above the chart sums it up: "12 rule failures in 30 days · 3 of 9 runs failed · last run Failed".

The chart reads the runs in the page's Run history, so the two never disagree. If the validation ran before but not in the last 30 days, the card reads "No runs in 30 days — last run …"; while its only recent run is still going, it says a run is in progress (a run joins the chart once it finishes). Only a validation that never ran reads "Not yet run".

Each run in Run history still shows that run's own health score: the pass rate of that one run, not blended with earlier runs.

A run that errors out before evaluating any rule (for example, the data source is unreachable) finalises a result and updates Last run, but contributes no checks, so an infra blip never zeroes a healthy validation's health score.

Note (agent-mode assets): an agent asset's run is pull-based — your on-prem Privacy Agent claims and completes it. If the agent reports a per-asset failure, the run still finalises over what landed (the failed asset counts as a failed child). But if the agent is offline and never claims the asset, that asset's part of the run stays pending and the validation stays running until the agent comes back. Keep your agent healthy, or take its assets' rules out of the validation while it's down.

Related

• Create and run a validation — the step-by-step version of this page.
• Schedule a validation
• Execution runs and Results — what a run produces.