Quality Dashboard

The catalog-wide Data Quality Dashboard at /data-quality — three breakdown rings, six anomaly-class metrics, and the per-side filter sets for tables and tests.

The Data Quality Dashboard at /data-quality is the catalog's cross-entity quality view. It builds on top of the test results imported through the Test Results Import paths — Great Expectations, dbt, odd-collector-profiler, and custom frameworks — and renders them as one operator-friendly summary.

Quality checks are not performed inside ODD Platform — the dashboard surfaces results from the integrated tools.

Data Quality dashboard — three pie charts at the top (Table Health 88 tables: 42 success / 28 failed / 18 broken; Test Results Breakdown 335 tests: 273 passed / 32 failed / 30 skipped; Monitored Tables 98: 87 monitored / 11 unmonitored) and a per-test-category matrix on the right showing per-anomaly-class counts. The left rail carries two filter sets — one for tables, one for tests.

Three breakdown rings

The dashboard's hero row is three pie charts, each computed across the catalog at the time the page is loaded:

• Table Health — the count of tables broken down by their aggregate health status (success / failed / broken).

• Test Results Breakdown — the count of test runs broken down by status (passed / failed / skipped).

• Monitored Tables — the count of tables broken down by whether they are monitored (have at least one DQ test) or unmonitored.

The "Monitored vs Unmonitored" framing applies specifically to Table-type datasets — the catalog's primary tabular entities.

Six anomaly-class metrics

The right-side matrix shows the breakdown of failures across the six anomaly classes the platform recognises. Each metric represents a dimension of data quality:

• Assertion Tests — validations or checks put in place to ensure that specific conditions or assertions about the data are met.

• Column Values Anomalies — irregularities or unexpected values in the data that deviate from a predefined set of acceptable or standard values.

• Freshness Anomalies — staleness signals — checking whether the data is up-to-date and falls within the acceptable time frame.

• Schema Changes — modifications in the structure or organization of the data, with a focus on monitoring whether the data schema remains consistent over time.

• Unknown Category — data placed into a category that was not foreseen or specified in the established data model or schema.

• Volume Anomalies — unexpected changes in the quantity or volume of data.

For each of these metrics the dashboard assigns statuses to the checks, distinguished by colors for better visualization:

Checks Statuses distinguished by colors

Monitored vs unmonitored portions

Beyond the per-anomaly breakdown, the dashboard reports what portion of data was monitored and what portion was skipped:

Monitored / unmonitored tables portions

This applies specifically to Table-type datasets — the catalog's primary tabular entities.

Filtering

Filter the dashboard by five dimensions: Namespace, Datasource, Owner, Title, and Tag. The filters apply on two separate sides:

• Tables-side filters — narrow the Table Health and Monitored Tables rings to the selected slice of tables.

Filters for tables

• Tests-side filters — narrow the Test Results Breakdown ring to tests with the selected attributes.

Filters for tests

The two filter sets are independent — you can hold the tables-side filter at one slice and the tests-side at another, which is useful when reasoning about test coverage across a slice of tables.

ODD users can narrow down test results for datasets by multiple attributes simultaneously.

Filtering by multiple attributes simultaneously

AND-only conjunction. For simplicity the platform implements only one logical conjunction across filter dimensions — AND. The results displayed after filtering are the outcome of all selected filters intersected together.

Where to next

• Test Results Import — how the test results that populate the dashboard land in the catalog.

• Dataset Quality Statuses (SLA) — operator-set severities on test results that feed the dataset-level SLA.

• Alerting — DQ-test-failed alerts feeding through the alert lifecycle.

• Visibility for Data Quality Engineer — the dashboard in the context of the DQ-engineer end-to-end workflow.