Data Quality Rules let you validate, enrich, and clean up source records for a specific entity before they're matched and merged into golden records.
Overview
You add Data Quality Rules directly on an entity inside a model, from Ontology › [model] › Entities › [entity] › Data Quality Rules. Every rule you build here runs automatically on incoming source records during sync, before matching and merging happen — so problems get caught and handled while a record is still raw, not after it's already become part of a golden record.
This screen is different from the standalone Data Quality monitoring product elsewhere in the platform: that product scans and reports on data at rest, while the rules described here are entity-level checks you author yourself, wired into the ingestion pipeline of a single model. To create a rule you need Edit access to the model — without it, the New Data Quality Rule button simply won't appear.
Rule Types
Every rule you create belongs to one of three types, and for each type you can either build a custom rule from scratch or start from a ready-made template.
| Rule Type | What it does |
| Validation | Checks incoming data for accuracy and correct formatting. |
| Enrichment | Adds or updates information on a record by pulling in additional data. |
| Cleansing | Standardizes data and removes inconsistencies, such as inconsistent casing or formatting. |
Building a Rule
Click New Data Quality Rule and you'll move through a short stepper:
Rule Type — choose Validation, Enrichment, or Cleansing, then decide whether to start from a custom rule or a template.
Define Rule — configure the conditions and logic the rule checks. A rule can also run an Automation as its check instead of (or alongside) simple conditions.
Configure Output — for Enrichment rules only, map the automation's output parameters to entity fields so you control exactly where the enriched data lands.
Actions Post Check — decide what happens to records that satisfy the rule's conditions (see below).
Apply Filters — narrow which records the rule actually runs against, rather than applying it to every incoming record.
What Happens When a Rule Fails
In the Actions Post Check step, you set the action to be executed on records satisfying the rule, choosing one of two outcomes:
Accept records with warning — the record keeps moving through the pipeline, but it's flagged with a warning for reviewers to see later.
Reject record — the record is pulled out into Rejected Records for review instead of continuing on.
Whichever action you pick, you must write a warning or rejection message. Type {{ in the message field to insert dynamic data pulled from the record itself, so reviewers can immediately see why a given record was flagged rather than having to dig for the reason.
Note: if a rule's underlying Automation errors out while checking a record, the platform rejects that record automatically with its own generated message (something like "Automation execution failed: …") instead of using your authored text. If you see an unfamiliar rejection reason, it usually means the checking automation broke — not that the data itself is unusually bad.
Where Results Show Up
Rule outcomes surface in two places depending on the action taken. Records rejected by a rule land in the model's Quarantined Records › Rejected Records, where you can correct and re-submit them. Records that were merely warned show up as Data Quality Insights on the golden record itself — the Records screen displays an insights pill per record, and opening a record shows exactly which rules produced which insights during resolution.
Managing Existing Rules
The Data Quality Rules list shows every rule defined on the entity. From each row's menu you can edit a rule, clone it, or open a read-only details view. Deleting a rule asks for confirmation first and can't be undone, so double-check before you confirm.
Cloning a Rule
Use Clone from a rule's row menu to duplicate it quickly. This opens a dialog titled Clone [rule name] with:
A required Name field, prefilled as "[name] (copy)".
A Description field, prefilled from the source rule — edit either field before saving if you need to.
A Clone the associated automation checkbox, on by default.
Leave the automation checkbox on and a rule that runs an Automation as its check gets its own independent copy of that automation. Switch it off and the clone keeps pointing at the same automation as the original — meaning any later edit to that automation changes what both rules run. Click Clone to save the copy and jump straight to its edit page, or Cancel to close without creating anything.
The clone is always created disabled, regardless of whether the source rule was on or off, so it won't run until you switch it on from the list. Cloning requires the same Edit access as the rest of the Data Quality Rules screen.
Notes
Rules run during sync, before matching and merging — they act on source records, not on already-formed golden records.
Without Edit access to the model, you won't see the New Data Quality Rule button or the Clone action.
An unexpected, platform-generated rejection message almost always points to a failing Automation, not bad source data.
Cloning with the automation checkbox off links two rules to one automation — changing that automation later affects both rules at once.
Deleting a rule is permanent; there's no undo after you confirm.