# Dataset Quality Statuses (SLA) Mark the importance of each test on a dataset using **Minor**, **Major**, and **Critical** severities. The platform aggregates those severities together with the test pass / fail counts into a single dataset-level **SLA colour** (Green / Yellow / Red) that downstream BI reports can import directly. ## Setting severities Severities are operator-set — the platform does not infer them. 1. Open the dataset's main page and select the **Test reports** tab. 2. Click on a job (a test result row) and, in the right-side panel, choose a severity — Minor, Major, or Critical. Severities apply per-test, not per-dataset; one dataset can carry tests at all three severities. Each test's severity together with whether the latest run passed feeds the dataset's aggregate SLA colour. ## Importing SLA into BI reports Each dataset exposes its current aggregate SLA through **two endpoints** — one returns a pre-rendered PNG badge, the other returns the structured JSON report. Use whichever fits your BI tool's integration model. | Endpoint | `Content-Type` | Use for | | ----------------------------------------------- | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `GET /api/datasets/{data_entity_id}/sla` | `image/png` | A pre-rendered PNG badge (1–2 KB). Suitable for BI tools that can embed an image URL directly (Confluence macros, Notion image embeds, Excel `IMAGE()` formula, Looker / Tableau image tiles). | | `GET /api/datasets/{data_entity_id}/sla_report` | `application/json` | The structured `DataSetSLAReport` — current SLA colour (`GREEN` / `YELLOW` / `RED`), severity-weights breakdown, and a `sla_ref` self-link. Use this when your BI tool parses JSON (BI dashboards that compute their own visualisation, custom report pipelines, internal-tools dashboards). | In both cases `{data_entity_id}` is the numeric ID of the dataset's data entity — the same ID that appears in the dataset's catalog URL. **Choosing between the two:** if your destination renders an image natively, the `/sla` PNG is one HTTP call and zero parsing. If your destination needs the underlying numbers (per-severity counts, severity-weights breakdown), the `/sla_report` JSON is the only path — the PNG does not carry the structured data. ## How the SLA colour is computed The SLA colour is **not** a direct severity-to-colour mapping — it is computed across the dataset's tests by `SLACalculator` based on which severities have failing tests: * **Red** — at least one Critical test is failing, OR all Major-severity tests are failing, OR a particular all-but-one-Major-failing-and-all-Minors-failing pattern. * **Yellow** — some Major tests failing (but not all), OR all Minor tests failing, OR no tests at any severity defined yet (the platform errs cautious when nothing is defined). * **Green** — none of the above; passing tests dominate at every severity. So changing a single test's severity from Major to Critical can flip the dataset from Yellow to Red without any test pass / fail status changing. Use severities to encode "how loud should this dataset's failure be" rather than as a labelling exercise. ## Known operator caveats {% hint style="warning" %} **Tests without an operator-set severity contribute to the SLA aggregate as Major.** The platform's mapper returns `MAJOR` as the default severity for any test row that has no explicit entry in the severity table. An operator who never opens the Test reports tab to set severities, or one who relies on the page's "severities are operator-set — the platform does not infer them" framing literally, still has every test contributing to the SLA — at `MAJOR` weight. A dataset with 100 unset-severity tests and 1 Critical-failing test renders **Red**, not because of the one Critical test alone but because the 100 default-Major tests count against the SLA aggregate. To exclude tests from the SLA aggregate, mark them `Minor` (or wait for the upstream `severity_source` discriminator that would separate operator-set values from defaults). {% endhint %} {% hint style="warning" %} **The four DQ read endpoints behind this page are reachable to any authenticated user — there is no per-owner gate.** `GET /api/datasets/{data_entity_id}/dataqatests`, `GET /api/datasets/{data_entity_id}/test_report`, `GET /api/datasets/{data_entity_id}/sla`, and `GET /api/datasets/{data_entity_id}/sla_report` are not enumerated in the platform's authorization rules; the catch-all "any authenticated user" rule covers them. Authenticated callers under `LOGIN_FORM` / `OAUTH2` / `LDAP` read every dataset's DQ tests and SLA regardless of dataset ownership. Multi-team deployments that require per-team DQ-result isolation must enforce it at the network perimeter (reverse proxy rules, ingress filtering) or rely on the existing `DATASET_TEST_RUN_SET_SEVERITY` permission to gate writes only — the read side is not configurable in the platform's RBAC today. {% endhint %} {% hint style="warning" %} **Severity changes are not logged in the Activity Feed today.** Changing a test's severity through the Test reports tab or the API gates on the `DATASET_TEST_RUN_SET_SEVERITY` permission but does **not** emit an Activity Feed event, does not stamp `last_modified_by` on the row, and does not version the prior severity. The SLA colour flip is observable downstream (in the platform UI and in BI tools embedding the colour through the endpoints above), but the platform-side signal of *who* triggered it is unavailable without direct database inspection. Compliance and audit workflows depending on SLA-colour history must instrument severity changes externally until the upstream activity-event emission ships. The wider audit-scope picture and the compensating controls operators can apply are documented on the [Audit trail scope](/configuration-and-deployment/enable-security/audit-trail-scope.md) page. {% endhint %} ## Where to next * [Test Results Import](/features/data-quality/test-results-import.md) — how the test results that the SLA aggregates land in the catalog. * [Quality Dashboard](/features/data-quality/dashboard.md) — the catalog-wide quality view that surfaces test outcomes alongside the per-dataset SLA. * [Alerting](/features/active-platform-features/alerting.md) — DQ-test-failed alerts (which fire on the test-result event the SLA also consumes). * [Visibility for Data Quality Engineer](/use-cases/use-cases/dq-visibility.md) — the DQ-engineer use case end-to-end. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.opendatadiscovery.org/features/data-quality/sla-statuses.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.