Data Quality is quality monitoring layered on top of the data you've already connected. Instead of asking you to trust a table blindly, it lets you add that table to a monitoring suite, attach checks that make sense for its fields, and run scans that turn "is this data any good?" into a set of scores you can track over time.
Overview
You reach Data Quality from the data-governance area of the platform. It opens on a list of monitoring suites — containers you create to group the datasets you want to check together, along with their schedule and results. Its side navigation adds two more areas: a Business Ontology of reusable business terms, and a Rules library holding the underlying checks. Together they take you from "here's a table" to "here's how healthy that table is, and why."
The three-part navigation
Everything in Data Quality lives under one of three areas, each with a distinct job.
Monitoring Suite
Where you do the hands-on work: add the objects (tables or datasets) you want monitored, review what gets profiled, assign checks to their fields, and run scans. Each suite tracks its own objects, scans, and scores, and you can put it on a recurring schedule — by interval or cron expression — so it scans automatically instead of only when you click Start Scan.
Business Ontology
A library of business terms — "Email Address," "Customer ID," "Order Amount." Each term bundles rules that recognize it in your data with quality checks that should run wherever it appears. Once set up, any matching field gets tagged automatically during profiling and inherits the term's checks, so you're not wiring them up field by field.
Rules
Where the underlying logic lives, in two kinds. Detection Rules recognize a piece of data — the pattern behind "this looks like an email" — and power auto-tagging. Evaluation Rules judge data once it's found — the logic behind "this email is valid" — and power scan scores. Both are reusable: build once, attach wherever needed.
The five quality dimensions
Every evaluation rule measures one of five dimensions, and every scan reports a score for each of them:
| Dimension | What it checks |
| Validity | Whether data follows the correct format, content rules, and relationships between fields. |
| Uniqueness | Whether duplicate records exist, and whether values that should be one-of-a-kind actually are. |
| Completeness | Whether required fields actually contain values instead of being empty or null. |
| Accuracy | Whether values match against a trusted reference source. |
| Timeliness | Whether data is available when needed and reflects the current state of the world. |
A scan rolls results up into a percentage score per dimension, plus an overall score, so you can see at a glance which dimension — and which object — needs attention.
How it all connects end to end
The three areas aren't separate tools — they're stages of one pipeline:
Datasets come in. Catalog assets and connected applications supply the tables you add to a monitoring suite as objects.
Detection rules tag them. During profiling, each object's fields are checked against active detection rules; matching fields are automatically tagged with the matching business term.
Terms attach evaluation rules. Every term carries its own evaluation rules, so a tagged field inherits the right checks. You can also attach or remove terms and rules manually where auto-tagging gets it wrong.
Scans score the data. Running a scan applies every assigned evaluation rule to every record, producing dimension scores, an overall score, and a record-level breakdown you can drill into.
Because terms carry both detection and evaluation logic, you typically define what "a valid email" looks like once, rather than repeating that logic on every object with an email field.
Notes
A suite's scan controls stay hidden until it has at least one object added — add and profile objects first.
If a term isn't auto-tagging fields you expect, check that its detection rule covers data (not just metadata), targets exactly one attribute, and that its match threshold isn't set too high for noisy data.
Evaluation rule sets are evaluated in order and stop at the first match, so put your most specific conditions first.
Records that don't match a rule's filter conditions show up as "Skipped" rather than pass or fail — a high skip count usually means the filter needs adjusting.