> For the complete documentation index, see [llms.txt](https://docs.opendatadiscovery.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.opendatadiscovery.org/features/data-quality.md).

# Data Quality

The **Data Quality** section of ODD Platform is the home for the catalog's correctness signals — test results pushed in from quality frameworks, the cross-catalog quality dashboard, and the operator-set dataset SLA statuses that downstream BI reports consume.

ODD covers Data Quality fully *as an aggregator*. Quality checks are not performed inside ODD Platform — the platform integrates with leading tools in the field and surfaces their results in one operator-friendly view. See the [Data Governance map](/introduction/main-concepts.md#data-governance-map) for the position of Data Quality among the other governance pillars.

Open it from the top-level navigation **Data Quality** tab (the catalog-wide dashboard) or from any data entity's **Test reports** tab (per-entity test results and SLA status).

## Subsections

* [**Test Results Import**](/features/data-quality/test-results-import.md) — how test results land in the catalog: push-client integrations with [Great Expectations](/integrations/integrations/odd-great-expectations.md) and [dbt](/integrations/integrations/odd-dbt.md), statistical profiles via [`odd-collector-profiler`](/integrations/integrations/odd-collector-profiler.md), and a custom-framework escape hatch via `POST /ingestion/entities`.
* [**Quality Dashboard**](/features/data-quality/dashboard.md) — the catalog-wide quality view at `/data-quality` — three breakdown rings (Table Health / Test Results / Monitored Tables), six anomaly-class metrics, and the per-side filter sets (tables vs tests).
* [**Dataset Quality Statuses (SLA)**](/features/data-quality/sla-statuses.md) — Minor / Major / Critical statuses on test results, the dataset-level aggregate SLA colour, and two endpoints for BI import: `/api/datasets/{data_entity_id}/sla_report` (the JSON report) and `/api/datasets/{data_entity_id}/sla` (a pre-rendered PNG badge).
* [**Test Run History**](/features/data-quality/test-run-history.md) — the per-test runs timeline (`/dataentities/{id}/history`) — every individual run, the `status_reason` diagnostic each upstream framework writes, status filter, infinite-scroll pagination, and the cross-owner read posture on `status_reason` text.

## Why this is a separate pillar

For how Data Quality relates to the other governance pillars (Data Discovery, Data Modelling, Master Data Management, Data Lineage, Data Glossary), see [Main Concepts → Data Governance map → Pillar differentiation](/introduction/main-concepts.md#pillar-differentiation) — the canonical home for the six-pillar framing. Quality is its own pillar because the correctness signal cuts across every catalogued dataset; this landing consolidates the three ways an operator interacts with it (ingest test results, view the catalog-wide dashboard, curate per-dataset SLA statuses for BI consumption).

## Where to next

* If you are connecting a quality framework into the platform → [Test Results Import](/features/data-quality/test-results-import.md).
* If you are auditing the catalog's overall quality posture → [Quality Dashboard](/features/data-quality/dashboard.md).
* If you are exposing dataset-level quality to BI reports → [Dataset Quality Statuses (SLA)](/features/data-quality/sla-statuses.md).
* For the data-quality-engineer use case end-to-end → [Visibility for Data Quality Engineer](/use-cases/use-cases/dq-visibility.md).
* For DQ-test-failed alerts and where they surface → [Alerting](/features/active-platform-features/alerting.md).
* For the broader catalog vocabulary → [Main Concepts](/introduction/main-concepts.md).