> 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/deploy-at-scale.md).

# Deploy at scale

Writing a Data Standard defines a rule. **Deploying** it is what **makes that rule enforceable** across your data landscape. When you create a Data Standard in Soda Cloud, you give it a **scope**, and Soda automatically links the standard to every dataset the scope selects. Then, Soda keeps that set of datasets up to date as your data landscape changes.

That is the core value of Data Standards: **you maintain one rule**, and **it applies to every dataset** that should follow it, including datasets onboarded after the standard was created.

{% hint style="warning" %}
Creating and managing Data Standards requires the **Manage data standards** permission. Data Standards must also be enabled for your organization.
{% endhint %}

## Elements of a Data Standard

A Data Standard is made up of the following:

<table><thead><tr><th width="160">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Name</strong></td><td>A unique name that identifies the standard within your organization.</td></tr><tr><td><strong>Label</strong></td><td>A human-readable display name shown in Soda Cloud.</td></tr><tr><td><strong>Description</strong></td><td>Optional context explaining what the standard enforces and why.</td></tr><tr><td><strong>Contents</strong></td><td>The Data Standard YAML, including the checks to run.</td></tr><tr><td><strong>Scope</strong></td><td>The rule that selects which datasets the standard applies to (see below).</td></tr><tr><td><strong>Status</strong></td><td>The lifecycle state: <code>draft</code>, <code>active</code>, or <code>paused</code>.</td></tr><tr><td><strong>Owners</strong></td><td>The users or groups responsible for the standard. At least one owner is required.</td></tr></tbody></table>

## Scope: selecting datasets

The **scope** determines **which datasets** a standard is enforced on. You define it in the editor using one of two modes:

* **Rules** – match datasets by pattern. Each rule targets a **data source**, with an optional **schema pattern** and **dataset pattern**. Patterns support wildcards (for example, `customer_data_*`), so a single rule can match many datasets, and you can add several rules to cover datasets across different data sources or schemas.
* **Datasets** – select specific datasets explicitly.

<figure><img src="/files/3m9OERKhtaAu1sH5mjHo" alt="" width="563"><figcaption><p>Defining scope with rules: each rule matches datasets by data source, schema pattern, and dataset pattern.</p></figcaption></figure>

Because rules match by pattern rather than a fixed list, **Soda re-evaluates the scope against your catalog** and links the standard to every matching dataset. You can re-run this at any time with **Refresh scope** to confirm exactly which datasets the standard targets.

{% hint style="info" %}
**Scope is evaluated continuously**, not just once. When a new dataset is onboarded that matches an active standard's scope, the standard is automatically linked to it, no manual step required. This is what keeps a standard enforced "at scale" as your data grows.
{% endhint %}

## Status and lifecycle

A standard's **status** controls whether and how it is enforced:

{% stepper %}
{% step %}

### Draft

**The standard is saved but not enforced.** Use this state to author and review a standard before it affects any data. No datasets are linked and no scans run.
{% endstep %}

{% step %}

### Active

**The standard is enforced.** Soda links it to every dataset matching its scope and runs its checks on the configured schedule. New matching datasets are picked up automatically.
{% endstep %}

{% step %}

### Paused

**Enforcement is temporarily suspended.** Existing dataset links are preserved, but no new scans run until you set the standard back to "active". Use this to pause a noisy or in-progress standard without losing its configuration.
{% endstep %}
{% endstepper %}

<figure><img src="/files/rwLEcp44vV1Sosy3n7A1" alt=""><figcaption><p>Switch a standard's status from its page in Soda Cloud.</p></figcaption></figure>

## Ownership

Every Data Standard has one or more **owners** (users or user groups). Owners are responsible for the standard and are who Soda surfaces when a standard needs attention. Assign owners that reflect accountability for the rule, typically a data governance or platform team.

## Scheduling

Once a standard is active, Soda keeps validating every linked dataset over time without manual intervention. A standard does not carry its own cron expression; instead, its checks run **per dataset**, on that dataset's Data Standards schedule.

* **Default from the data source.** Each dataset inherits its Data Standards schedule from the **default schedule set on the data source connection page**, the same default used for contract verification. Set it once per data source and every dataset it contains picks it up.
* **Per-dataset override.** A dataset owner can change the schedule, or turn scheduled verification off entirely, from the **dataset's settings dialog** in Soda Cloud.

This is why the same standard can run at different times against different datasets: each linked dataset runs on its own Data Standards schedule, defaulting to its data source's default.

> Learn how the data source default schedule works: [Broken mention](broken://pages/adn2iQZu7t1aWGfkGzSJ#scheduled-execution-from-the-contract-editor).

## How results stay organized

Because a standard runs across many datasets, Soda tracks its results **per dataset** while keeping them grouped under the standard. This lets you answer both questions that matter at scale:

* *Is this dataset compliant with all the standards that apply to it?*
* *Is this standard being met across every dataset it targets?*

> See [Review results](/data-testing/data-standards/review-results.md).

## Next steps

* Run a standard from the CLI: [Verify a Data Standard](/data-testing/data-standards/verify-a-data-standard.md)
* Review results across datasets: [Review results](/data-testing/data-standards/review-results.md)

***

{% 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/deploy-at-scale.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.