Data standards that enforce themselves
Naming conventions, ownership rules and data contracts live in a wiki page and get checked in review, when someone remembers. Data Workers lets you write each standard once, checks every change against it and turns every gap into a fix for a named owner to approve.
Before and after
| Today | With Data Workers |
|---|---|
| Standards in a wiki page nobody opens | Each standard written once, with a named owner |
| Naming and tagging checked in review, when someone remembers | Every change checked against the standard as it is made |
| Missing owners, docs and tests found in an audit | Gaps found the day they appear, with a fix proposed |
| Exceptions that never expire | Exceptions that are explicit and expire |
| Adoption known by anecdote | Coverage per domain, measured against a week-one baseline |
Every new table, model and column is a chance to break a convention, and agents and analysts now create them faster than any reviewer can read them. A data governance policy template tells people what good looks like; this page is about making the standard check itself. Data contracts are one kind of standard, and the guide to what a data contract is covers the vocabulary.
How it works
1. Write the standard once
State the rule in plain terms: every sensitive column classified, every table owned, every model tested, every name following your convention. The Data Context & Catalog agent records it with define_business_rule. Each standard has a named owner, and each exception is explicit and expires, so nobody has to remember to revisit it.
2. Check every change
When a pull request adds a table, a model or a column, the Data Access & Governance agent checks it against the standards with check_policy. The Schema Evolution agent uses check_compatibility to flag a change that would break a contract with a downstream consumer before it ships. A producer sees the answer in the pull request, in the terms of your own conventions. For contracts in dbt, see data contracts in pull requests.
3. Turn every gap into a fix
Gaps become work. flag_documentation_gap finds the table with no description or owner, auto_tag_dataset proposes the missing tags, and create_quality_tests_for_pipeline drafts the missing tests. Each fix goes through the normal approval path to the standard's owner, and the Autonomous Data-Conductor shows per domain how far each standard is met and what the agents are doing about the rest.
The impact metrics we move
- •Change reviewed against standards: from about 2 days to under 15 min
- •Standards coverage report per domain: from about 2 days to 1 h
- •Unowned table assigned an owner: from about 2 days to 1 h
Where teams start
- •Ownership. Every table in one domain has a named owner, and the unowned ones get a proposed owner.
- •Documentation. New tables ship with a description, and the undocumented backlog gets drafts for review.
- •Test coverage. Every dbt model behind an executive dashboard has tests, drafted as pull requests.
- •Naming conventions. Schemas, tables and columns checked against your convention as they are created.
- •Contracts on shared tables. Breaking changes to tables other teams depend on are flagged before they merge.
What powers it
Autopilot Standards holds the rules, Autopilot Routines sweep for gaps on a schedule and when something changes, and the Autonomous Data-Conductor coordinates the agents and shows what is waiting for approval. The Data Context & Catalog agent owns documentation, tags and ownership in the Spellbook Data Catalog, the Data Access & Governance agent checks policy, and the Quality Monitoring and Schema Evolution agents cover tests and contracts. Where this shows up in practice:
For the chief data office view of the same idea, see the agentic data office.
The climb: from assisted to autonomous to agentic
Every transformation runs on the ladder from our thesis. Agents start by watching and suggesting (L0 to L2 run today), and a domain can move further up on evidence from its own receipts. A standard that is only measured today can be enforced tomorrow once its owner trusts the record. For how contracts are set up step by step, read how to implement data contracts.
The pilot
- •Scope. One domain, three to five standards (ownership, documentation, tests, naming, sensitive columns tagged) and the dbt project that builds it.
- •First week. Agents start by watching and suggesting: they record a week-one baseline of coverage, list the gaps and show the fixes they would have proposed, with receipts.
- •By week two. New changes are checked as they are made, fixes arrive as proposals for each standard's owner, and anything sensitive stays with a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •Change reviewed against standards: from about 2 days to under 15 min
- •Standards coverage report per domain: from about 2 days to 1 h
- •Unowned table assigned an owner: from about 2 days to 1 h
- •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.
FAQ
Who decides what the standards are? You do. Each standard has a named owner on your side, and the agents hold every domain to it.
Will agents rename or change our tables? No. They propose fixes, and the standard's owner approves them through the normal approval path before anything changes.
Is everything blocked automatically? Not everywhere. Standards on catalog and schema changes are checked as changes are made; others are measured and reported, and the gaps become proposed work.
What about exceptions? Each exception is explicit, has an owner and expires, so a one-off does not become permanent.
Do we have to replace dbt tests or our contract tooling? No. The agents work alongside your dbt project and existing checks; compare the options in data contracts vs schema registry.