Your data quality rules, run natively in Snowflake or Databricks.
Move your approved rules into the native data quality features the platforms now provide. No separate ETL jobs to run them, no data quality tool to buy, and your data steward gets an email when a rule fails.
Approved rules
What must be true of each table, approved by your business
GitHub
One versioned copy, the same in dev, test and production
AI coding agent
Turns each rule into a native check; our engineer reviews every one
Native checks on each tablebuilt into the platform
Data loads
The table's usual load, kept in place
Checks run natively
Inside the platform, on the table itself
Results recorded
In the platform's own results, nothing to build
- Failure alertAn email to the data steward
- Data quality reportScores and trends in Power BI
Defining the rules is one thing. Running them natively in Snowflake or Databricks is another.
Your business approved its data quality rules. They still run in separate ETL jobs, or a separate tool, that read the data, test it and keep the results somewhere else. Snowflake and Databricks now have native data quality features that run these checks themselves. The features are recent, so many teams still build and maintain the separate jobs.
Every rule running natively. Every failure reported.
Each approved rule becomes a native check on its own table, with no separate ETL job to maintain.
When a check fails, your data steward gets an email.
A report on every rule: its score, its trend, and which tables and columns the rules cover.
Six weeks from approved rules to native checks in production
Your rules go into GitHub
Each approved rule goes into your GitHub repository as one versioned copy, the same in development, test and production.
AI drafts each check
An AI coding agent turns each rule into a native check on its table, and our engineer reviews every one.
The checks survive your loads
On Snowflake, a table that is dropped and rebuilt loses its checks, so we change those loads to keep them attached.
Tested, then released
We test every check against planted errors and clean data, your stewards sign off on the results, and we watch the first week in production.
Alert, report, handover
Failures email your data steward, a Power BI report shows scores and trends, and your team adds one rule on its own before we leave.
On each platform
| Snowflake | Databricks | |
|---|---|---|
| The native check | A data metric function with an expectation, built in or custom | An expectation on a table built by a Lakeflow pipeline |
| When it runs | Every time the table’s data changes | Every time the pipeline updates the table |
| The AI agent | Cortex Code | Genie Code, agent mode (Public Preview) |
| Where results go | Snowflake’s own data quality tables | The pipeline’s event log |
| Requires | Enterprise Edition or higher | Tables built by Lakeflow pipelines (Advanced edition on classic compute) |
One fixed fee. No data quality tool to buy.
One data domain, such as Finance or Supply Chain, of up to 100 tables · no limit on rules · one platform · six weeks
- Your approved rules as code in your GitHub, one versioned copy
- Native checks in development, test and production, on Snowflake or Databricks
- Load changes so every check stays attached
- An email to your data steward when a check fails, and a Power BI data quality report
- Two weeks of testing and release to production, then a handover where your team adds a rule
You bring
Every rule approved by your business and already written as SQL you have tested.
Add-on
Up to 100 more tables, their rules built, released and added to the alert and the report.
No license fee from us, and no data quality tool to buy. The checks run natively in Snowflake Enterprise Edition and in Databricks Lakeflow pipelines (Advanced edition on classic compute). You pay the platform for the compute the checks use.
What leaders ask us first
Our data quality tool already does this.
Are these features ready?
Our loads rebuild the tables.
We don’t have approved rules written as SQL yet.
What do we own afterwards?
What do we need in place?
Run your approved rules natively
Six weeks, one fixed fee, and every approved rule in one data domain running natively, with no separate ETL jobs to maintain.