> For the complete documentation index, see [llms.txt](https://docs.soda.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.soda.io/soda-documentation/data-testing/data-standards/review-results.md). # Review results Review Data Standard check results across every dataset they apply to. Once a Data Standard runs, whether on its schedule or from the CLI, its **results are available in Soda Cloud**. Because a standard applies to many datasets, you can read its results from two complementary angles: **per dataset** (is this dataset meeting the standards that apply to it?) and **per standard** (is this rule being met everywhere it's enforced?). ## Check outcomes Each check produced by a standard reports one of the following outcomes for its most recent run: * **Passed** – the data met the check's expectation. * **Warned** – the data crossed a warn-level threshold: a check whose threshold is set to `level: warn`, or the warn threshold of a check that carries both a fail and a warn threshold (see [Contract Language reference](/soda-documentation/reference/contract-language-reference.md#warn-and-fail-thresholds)). Standards use the same check language as contracts, so a check can warn before it fails. * **Failed** – the data violated the check. * **Error** – the check could not be evaluated due to a configuration, connectivity, or runtime issue. Soda tracks each check's results under its standard, so the same check is correlated consistently every time the standard runs and across every dataset it touches. This is what lets you trust a check's history even as a standard fans out across your data. ## Per-dataset view From a dataset's page in Soda Cloud, you can see the checks contributed by every standard that applies to that dataset, alongside any contract checks. This answers: *does this dataset comply with all the rules that target it?*

Checks contributed by Data Standards appear on the dataset, with a Linked standards panel listing each applied standard and its check count.

A **Linked standards** panel lists every standard applied to the dataset and how many checks each one contributes, so you can see at a glance which rules are in force. Selecting a check opens its detailed view, with the same tabs used for contract checks: * **Historical plot** – how the check has behaved across runs over time, helping you spot recurring issues and confirm fixes. * **Result** – a summary of the most recent run: status, measured value, time of execution, and any linked incident. * **Diagnostics** – execution metadata explaining how the result was computed (rows tested, failed rows count, and so on). * **Failed rows** – when failed row storage is configured, the specific records that violated the rule. > These tabs work the same way as for contract checks. See [Review checks](/soda-documentation/data-testing/cloud-managed-data-contracts/review-checks.md) for a detailed walkthrough. ## Per-standard view From a standard, you can see how it is performing across **every dataset** it is linked to: the number of matched datasets, the overall passing rate, and a **Matched datasets** list with each dataset's check results and compliance. This answers: *is this rule being met across the fleet?*, and helps you quickly identify which datasets are out of compliance with an organization-wide policy.

A standard's page: matched datasets, overall passing rate, scope, and per-dataset compliance.

## Store failed rows and results in the Diagnostics Warehouse Failed rows and check results from Data Standard verifications can also be stored in your [Diagnostics Warehouse](/soda-documentation/diagnostics-warehouse.md), a location in your own data source that Soda writes diagnostic data to. This keeps the underlying records and results in your environment, where you can query them directly, join them with other data, and investigate failures at scale without the data leaving your infrastructure. > Learn how to set this up in [Broken mention](broken://pages/E1KTiEL4c6zytpedbEZg). ## Notifications and incidents Because Data Standard results flow into the same results model as the rest of Soda Cloud, you can route failures through **notifications** and turn them into **incidents** for triage and follow-up, using check attributes to control who gets alerted. > Learn more about [Notifications](/soda-documentation/manage-issues/notifications.md) and [Incidents](/soda-documentation/manage-issues/incidents.md). ## Closing the loop **Reviewing results** is what turns a Data Standard from a written policy into an **enforced** one. The standard defines what "good data" means across your organization; these views show, for every dataset it touches, whether the data currently meets that bar, and give you the detail needed to investigate and resolve any violation.
*** {% hint style="info" %} You are **not logged in to Soda** and are viewing the default public documentation. Learn more about [Licensing & documentation access](/soda-documentation/reference/documentation-access-and-licensing.md). {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.soda.io/soda-documentation/data-testing/data-standards/review-results.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.