> 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/verify-a-data-standard.md).

# Verify a Data Standard

Run a dataset's Data Standard checks on demand with the Soda CLI.

Verifying a Data Standard **runs its checks against real data** and **reports** whether the data meets the rule. Active standards are verified **automatically on their schedule** in Soda Cloud. You can also trigger a verification **on demand**, either from the dataset's page in Soda Cloud or from the **Soda CLI** (useful for CI/CD pipelines, custom orchestration, or reproducing a scheduled run locally).

## Verify on demand in Soda Cloud

You run a standard's checks from the **dataset's page**, not from the standard itself. Use the **Verify** button on the dataset to run its checks on demand.

By default, **Verify runs both the dataset's Data Standard checks and its Data Contract checks** in one go. To run just one, use the dropdown next to the button and choose the Data Standard checks (or the contract checks) individually.

{% hint style="info" %}
There is no "run" action on the standard editor itself. Because a standard fans out across many datasets, verification is always triggered per dataset, from that dataset's page.
{% endhint %}

## Verify a dataset's standards from the CLI

Use `soda data-standard verify` with `--dataset` (`-d`) to **fetch and run all active standards** that apply to a specific dataset, as resolved by their scopes in Soda Cloud.

```bash
soda data-standard verify \
  --dataset datasource/db/schema/customers \
  --data-source ds_config.yml \
  --soda-cloud sc_config.yml
```

This command:

* Fetches the active standards for the dataset from Soda Cloud, already resolved with the dataset and its active columns
* Connects to your data source using the configuration file
* Runs the checks and returns a pass/fail result

Because the standards are resolved by Soda Cloud, this run mirrors exactly what the scheduled cloud-managed verification does.

{% hint style="info" %}
`--dataset` requires `--soda-cloud`, since the active standards are fetched from Soda Cloud.
{% endhint %}

## Publish results to Soda Cloud

Add `--publish` (`-p`) to **send verification results to Soda Cloud** for visibility, history, and alerting.

```bash
soda data-standard verify \
  --dataset datasource/db/schema/customers \
  --data-source ds_config.yml \
  --soda-cloud sc_config.yml \
  --publish
```

> Learn how to connect the CLI to Soda Cloud: [Core CLI reference](/soda-documentation/reference/cli-reference.md#connect-to-soda-cloud).

## Override variables

If a standard declares variables, pass values at verification time with `--set`:

```bash
soda data-standard verify -d datasource/db/schema/customers -ds ds_config.yml -sc sc_config.yml --set ENV=prod
```

## Run a subset of checks

Use `--check-paths` (`-cp`) to run **only specific checks**, identified by their YAML path. This is useful for targeted debugging of a single check.

```bash
soda data-standard verify -d datasource/db/schema/customers -ds ds_config.yml -sc sc_config.yml \
  -cp data-standard.pii_rules:columns.email.checks.missing
```

A dataset can have several standards active at the same time, so a check path names **which standard** the check belongs to as well as where it sits inside that standard:

```
data-standard.<standard name>:<path within the standard>
```

Pass several paths to run a subset that spans standards:

```bash
soda data-standard verify -d datasource/db/schema/customers -ds ds_config.yml -sc sc_config.yml \
  -cp data-standard.pii_rules:columns.email.checks.missing \
     data-standard.freshness_rules:columns.updated_at.checks.freshness
```

{% hint style="info" %}
**On Soda Cloud**, the check path of a given check is on the check page, in the check info panel.
{% endhint %}

Because `.` and `:` separate the parts of a check path, a Data Standard's **name** cannot contain either character.

To select checks by their properties instead of their path, use `--check-filter`, or `-cf`. Check filters take the same syntax and fields as on `soda contract verify`, except `scope`: a Data Standard has no scopes, so `scope=base` matches every check and any other scope key is an error. A standard that declares `scopes`, or gives a check a `scope`, fails to load, and the other standards of the run still run. Each filter is a `key=value` expression, and `key!=value` excludes the checks that match. Filter on `standard` to run the checks of one standard:

```bash
soda data-standard verify -d datasource/db/schema/customers -ds ds_config.yml -sc sc_config.yml \
  -cf standard=pii_rules
```

Repeat `-cf` to add filters. This run skips the freshness checks and every check on the `email` column:

```bash
soda data-standard verify -d datasource/db/schema/customers -ds ds_config.yml -sc sc_config.yml \
  -cf type!=freshness -cf column!=email
```

Checks that the filters leave out do not run. With `--publish`, they go to Soda Cloud marked as excluded and keep their last status there, as they do with `soda contract verify`.

Filters also work with `-cp`. When a run has both, only the checks that match one of the check paths and pass the filters on the other fields run.

> Learn which fields a filter can use and how filters combine: [Core CLI reference](/soda-documentation/reference/cli-reference.md#check-filters).

## Command options

<table><thead><tr><th width="220">Option</th><th>Description</th></tr></thead><tbody><tr><td><code>--dataset</code>, <code>-d</code></td><td>A Soda Cloud dataset identifier. Fetches and verifies that dataset's active standards. Required.</td></tr><tr><td><code>--data-source</code>, <code>-ds</code></td><td>One or more data source configuration file paths. The first is treated as primary. Required.</td></tr><tr><td><code>--soda-cloud</code>, <code>-sc</code></td><td>Path to a Soda Cloud configuration file. Required.</td></tr><tr><td><code>--publish</code>, <code>-p</code></td><td>Send the verification results to Soda Cloud.</td></tr><tr><td><code>--set</code></td><td>Set a variable value, in the form <code>--set NAME=VALUE</code>. Repeatable.</td></tr><tr><td><code>--check-paths</code>, <code>-cp</code></td><td>One or more check paths to run a subset of the checks. Each path names its standard: <code>data-standard.&#x3C;name>:&#x3C;path></code>.</td></tr><tr><td><code>--check-filter</code>, <code>-cf</code></td><td>Filter checks by field, in the form <code>key=value</code>, or <code>key!=value</code> to exclude the checks that match. Repeatable. See <a data-mention href="/soda-documentation/reference/cli-reference.md#check-filters">Core CLI reference</a>.</td></tr><tr><td><code>--diagnostics-warehouse</code>, <code>-dw</code></td><td>Path to a diagnostics warehouse configuration file.</td></tr><tr><td><code>--verbose</code>, <code>-v</code></td><td>Display detailed logs during execution.</td></tr></tbody></table>

## Exit codes

`soda data-standard verify` returns the same exit codes as `soda contract verify`, so your pipeline can act on the result.

| Code | Meaning                                                                                                                                                                                                                                                                                                       |
| ---- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `0`  | All checks passed.                                                                                                                                                                                                                                                                                            |
| `1`  | One or more checks failed.                                                                                                                                                                                                                                                                                    |
| `2`  | One or more checks warned and none failed.                                                                                                                                                                                                                                                                    |
| `3`  | An error stopped a standard or the whole run. For example, a standard failed to parse, the data source connection failed, a check filter is malformed, the dataset has no active standards, a flag other than `--set` or `-cf` was given more than once, or an error was logged before the standards started. |
| `4`  | Results could not be sent to Soda Cloud.                                                                                                                                                                                                                                                                      |

A standard that errors does not stop the others. They still run and keep their own results, and the run exits 3.

With `--publish`, the results of all standards go to Soda Cloud in one upload.

On Soda Runner, when every standard stops on an error before it has results, the CLI marks the scan failed in Soda Cloud and attaches the run's logs.

## Next steps

* Review verification results across datasets: [Review results](/soda-documentation/data-testing/data-standards/review-results.md)

<br>

***

{% 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/verify-a-data-standard.md?ask=<question>&goal=<user_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.