Data Quality

Make quality part of execution, not a document after it.

Data Quality turns source-oriented expectations into repeatable SQL assertions with a clear pass condition, persisted QualityRun and bounded failure evidence.

Data Quality turns source-oriented expectations into repeatable SQL assertions with a clear pass condition, persisted QualityRun and bounded failure evidence.
Start from an explicit expectation.

Visual templates cover null, empty, unique, row-count, value-range, pattern, accepted-value and referential checks. Custom SQL supports more complex assertions when the pass condition is defined precisely.

Preview, save and run are different actions.

Preview tests the current interpretation. Save creates or changes the mutable rule. Run now or a supported Pipeline step creates the persistent QualityRun and a bounded finding when it fails.

Quality can control an implemented flow.

A standalone Data Quality job or Master control step can stop supported downstream work on failure. The exact PipelineRun, QualityRun and trigger remain separate records.

Least privilege remains essential.

Custom SQL does not have a universal independent read-only, single-statement parser. The SQL Console rule modal also requires the operator to rerun after editing SQL because a prior result does not prove the current draft. Sources should use least-privileged read credentials, and failure samples should exclude secrets and unnecessary personal data.

Current boundaries are not hidden.

QualityRule is mutable and is not directly pinned to DatasetVersion. Suite execution, automated repair, full finding remediation and confirmed notification delivery are not current capabilities. A managed Sandbox table participates through its project System Sandbox Source rather than a separate hidden quality path.

Start from an explicit expectation.

Visual templates cover null, empty, unique, row-count, value-range, pattern, accepted-value and referential checks. Custom SQL supports more complex assertions when the pass condition is defined precisely.

Null and empty-value checks

Uniqueness and row-count bounds

Numeric or comparable value ranges

SQL LIKE pattern and accepted-value checks

Referential-existence checks

Explicit custom SQL assertions

Preview, save and run are different actions.

Preview tests the current interpretation. Save creates or changes the mutable rule. Run now or a supported Pipeline step creates the persistent QualityRun and a bounded finding when it fails.

Preview is synchronous and non-persistent.

Save changes the mutable QualityRule definition.

Run now, Pipeline and Master execution persist a QualityRun.

Failure persists a bounded Data Quality finding; it is separate from the Assurance Finding workflow.

Quality can control an implemented flow.

A standalone Data Quality job or Master control step can stop supported downstream work on failure. The exact PipelineRun, QualityRun and trigger remain separate records.

Least privilege remains essential.

Custom SQL does not have a universal independent read-only, single-statement parser. The SQL Console rule modal also requires the operator to rerun after editing SQL because a prior result does not prove the current draft. Sources should use least-privileged read credentials, and failure samples should exclude secrets and unnecessary personal data.

Current boundaries are not hidden.

QualityRule is mutable and is not directly pinned to DatasetVersion. Suite execution, automated repair, full finding remediation and confirmed notification delivery are not current capabilities. A managed Sandbox table participates through its project System Sandbox Source rather than a separate hidden quality path.

Next step

Start with the flow that cannot afford ambiguity.

Bring the systems, owners, rules, delivery obligations and evidence requirements that matter.

Discuss a critical flow