> 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/data-testing/data-standards/review-results.md).

# Review results

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 threshold configured to raise a warning rather than a failure (using `level: warn`).
* **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?*

<figure><img src="/files/gL2KL2wVklqmlfIbIzUe" alt=""><figcaption><p>Checks contributed by Data Standards appear on the dataset, with a <strong>Linked standards</strong> panel listing each applied standard and its check count.</p></figcaption></figure>

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 [Broken mention](broken://pages/hqOaUlrcYskMagIB0QNj) 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.

<figure><img src="/files/YcmarYYLs6QiJFcsyWUh" alt=""><figcaption><p>A standard's page: matched datasets, overall passing rate, scope, and per-dataset compliance.</p></figcaption></figure>

## 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](/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 [Broken mention](broken://pages/GAK0Cdoq2hZmucVmrovV) and [Broken mention](broken://pages/SbOLXiiSRxTpmSKQeFyW).

## 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.

***

{% if visitor.claims.plan === 'datasetStandard' %}
{% hint style="success" %}
You are **logged in to Soda** and seeing the **Dataset Standard license** documentation. Learn more about [Documentation access & licensing](/reference/documentation-access-and-licensing.md).
{% endhint %}
{% endif %}

{% if visitor.claims.plan === 'enterprise' %}
{% hint style="success" %}
You are **logged in to Soda** and seeing the **Team license** documentation. Learn more about [Documentation access & licensing](/reference/documentation-access-and-licensing.md).
{% endhint %}
{% endif %}

{% if visitor.claims.plan === 'enterpriseUserBased' %}
{% hint style="success" %}
You are **logged in to Soda** and seeing the **Enterprise license** documentation. Learn more about [Documentation access & licensing](/reference/documentation-access-and-licensing.md).
{% endhint %}
{% endif %}

{% if !(visitor.claims.plan === 'enterprise' || visitor.claims.plan === 'enterpriseUserBased' || visitor.claims.plan === 'datasetStandard') %}
{% hint style="info" %}
You are **not logged in to Soda** and are viewing the default public documentation. Learn more about [Documentation access & licensing](/reference/documentation-access-and-licensing.md).

If you do have a Soda license, make sure to **log in to Soda Cloud in this same browser**.
{% endhint %}
{% endif %}


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.soda.io/data-testing/data-standards/review-results.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.