Precisely’s 2025 Outlook: Data Integrity Trends and Insights report (conducted with Drexel University’s LeBow College of Business) found that 77% of organizations rate their data quality as average or worse, and 67% don’t fully trust the data they use for decision-making. Asked about the biggest challenge to high-quality data, 49% named inadequate tools to automate data quality processes.

Source: Precisely and Drexel University’s LeBow College of Business, 2025 Outlook: Data Integrity Trends and Insights.

The people who understand the data best — governance leads, analysts, domain experts — still can’t define what “good data” means without filing a ticket and waiting for an engineer to write the check. The checks aren’t getting written fast enough because the interface excludes most of the people who know what to check.

That tooling gap is really a syntax gap. YAML is the right foundation for data quality checks — not because it’s fashionable, but because it determines who gets to participate.

The Conventional Wisdom: Write Checks in the Pipeline Code

The default assumption in data engineering is that Python is the right language for everything. And for a lot of things, that’s true. Python is expressive, flexible, and every data engineer already knows it.

That logic extends to data quality. Tools built on Python let you write arbitrarily complex validations, chain logic, build custom statistical tests, and plug into any framework. If you can code it, you can check it.

There are good reasons this became the norm. Data quality started as an engineering problem — engineers built the pipelines, so engineers built the tests. Python was already there, so Python became the language of data testing, and the checks lived in the pipeline code.

The problem is that this approach bakes in an assumption that hasn’t been true for years: that data quality is an engineering-only concern.

Why That’s Wrong

Data quality is everyone’s problem.

The data engineer who built the pipeline doesn’t know that the region_code column switched from ISO-2 to ISO-3 last quarter. The governance lead does. The analyst who noticed that revenue numbers stopped making sense on March 15th has the context the pipeline author lacks.

Those people usually don’t work in the pipeline code. But they can read and edit a YAML file.

When your data quality checks live where only engineers work, you get a bottleneck:

1. Business users spot the problem. They know the data semantics, they see when numbers look wrong, they understand domain rules that no schema can capture.

2. They file a ticket or send an email: “Hey, can someone add a check for X?”

3. It sits in a backlog. The data engineering team has pipeline work, migrations, incident response.

4. The check either never gets written or arrives weeks later. By that point, the bad data has already caused damage downstream.

This is the same anti-pattern that software engineering eliminated twenty years ago. When only specialists can define tests, testing becomes a bottleneck. The fix wasn’t better specialists. It was better interfaces.

What Actually Works: Declarative Checks as a Shared Language

YAML doesn’t make data quality better because of some inherent property of the format. It works because it shifts the interface for defining quality out of test code and into a declarative specification.

Here’s a data contract for an orders table in Soda contract language, with a null check on email:

dataset: datasource/db/schema/orders

checks:
  - row_count:
      name: "Orders table is not empty"
      threshold:
        must_be_greater_than: 0

columns:
  - name: email
    checks:
      - missing:
          name: "Less than 5% of orders have no email"
          threshold:
            metric: percent
            must_be_less_than: 5

That’s the whole contract. A governance lead can read it. A business analyst can propose a change to it in a pull request. A data engineer can review and merge it in thirty seconds.

This isn’t about YAML being “simpler” in some vague sense. It’s about three specific properties:

Declarative over imperative. YAML checks describe what good data looks like, not how to verify it. must_be_greater_than: 0 under a row count check reads like a specification, not a program. That’s the difference between a contract and an implementation.

Version-controlled collaboration. YAML files live in Git. Producers and consumers edit the same file. Changes go through pull requests, not email threads. This is the workflow that transformed software engineering (code review, CI/CD, automated testing) — and it works for data quality too.

Machine-readable by default. YAML slots directly into CI/CD pipelines. No wrapper scripts, no custom runners. A CLI tool parses the file, runs the checks, and returns pass/fail. That’s a circuit breaker you can drop into Airflow, GitHub Actions, or any orchestrator.

(If this sounds like the same argument for Infrastructure as Code, that’s because it is. We already proved that declarative YAML configs beat imperative scripts for managing infrastructure. Data quality is the same pattern.)

Data Contracts: Where YAML Really Shines

Data contracts are formalized agreements between data producers and consumers: what the schema looks like, what quality rules apply, who owns it, and what the SLAs are.

YAML is the dominant format for contract specifications — the Open Data Contract Standard uses it, Soda’s contract engine uses it, dbt uses it. And there’s a reason: contracts are documents that both humans and machines need to read.

Rules buried in test code only happen to encode agreements. A data contract written in YAML is the agreement — readable by the governance lead who defined the SLA, the engineer who implements the pipeline, and the CI/CD system that enforces it.

The real power is in the workflow that YAML enables. Instead of data producers and consumers arguing over email about what “valid data” means, they collaborate on a YAML file:

1. The consumer proposes a contract (or modifies an existing one) via a pull request

2. The producer reviews it — “We can guarantee freshness under 1 hour, but not under 15 minutes”

3. They negotiate in the PR comments, update the YAML, and merge

4. CI/CD enforces the contract automatically on every pipeline run

That’s governance packaged as engineering. No meetings. No Confluence pages that go stale. The contract is living, versioned, and enforced.

This is exactly how Make, the AI automation platform, shifted data quality left with data contracts in their Airflow pipelines.

When You Still Need Custom Logic

I’m not arguing that a YAML contract covers everything. For some data quality checks, you genuinely need custom logic:

• Statistical tests: Distribution comparisons, outlier detection with custom thresholds, seasonality-aware anomaly detection.

• Cross-dataset validations: Reconciliation with complex matching logic, beyond comparing counts, totals or rows.

• ML-based quality: Pattern recognition that goes beyond rule-based checks.

For these cases, custom SQL or code is the right tool. The better approach isn’t one or the other. It’s YAML as the primary interface for the checks that are standard (nulls, schema, freshness, row counts, uniqueness), with custom logic available for the rest.

The hybrid model works. Most data quality issues aren’t exotic. They’re a column that went null, a schema that changed without warning, a freshness SLA that was missed. YAML handles all of those in a file everyone can read.

How to Start: From Email Threads to Pull Requests

If your data quality checks live in pipeline code today, you don’t need to rewrite everything. Start here:

1. Audit your existing checks. List every quality rule your team enforces, including the informal ones hiding in Slack messages and email threads. Most teams are surprised by how many rules exist outside of code.

2. Translate the top 20 into YAML. Pick the checks that are standard validations: nulls, schema, row counts, freshness, uniqueness. These translate directly to declarative syntax.

3. Integrate into your pipeline. Drop the YAML checks into your CI/CD workflow. Soda Core or dbt tests can run them as quality gates (each tool reads its own YAML format).

4. Invite your non-engineering stakeholders. This is the step most teams skip. Share the YAML file with your governance lead, your business analyst, your data consumers. Show them how to propose a new check via a pull request. The first time a business user submits a PR that catches a data issue before it hits production, the value of this approach becomes obvious.

The Honest Caveats

YAML has real limitations. It doesn’t support conditional logic, it can’t express complex statistical tests, and deeply nested YAML files become harder to read than the scripts they replaced. If your quality checks require significant computation or cross-system orchestration, a declarative config file won’t cut it.

There’s also the “YAML isn’t unique” objection — you could get the same readability from TOML, JSON with comments, or a custom DSL. That’s true in theory. In practice, YAML has the ecosystem: most CI/CD tools are configured in it, every developer has encountered it, and the major data quality frameworks have already standardized on it. Switching costs matter.

The syntax you choose for data quality isn’t a technical detail. It’s an organizational decision that determines who gets to participate in defining what “good data” means.

Checks buried in pipeline code keep that power with engineers. A YAML contract distributes it across the organization.

Data quality is too important to be an engineering-only concern. The best syntax is the one that brings everyone to the table.

Check out the Soda contract language reference to see what YAML-based data quality checks look like in practice, or come discuss this in our Slack community.

Frequently Asked Questions