SQLMesh Audits as Open Data Contracts

A contract that cannot run is a policy document. A contract that runs but cannot explain its context is only half done.

The practical problem

SQLMesh audits validate model output after runs and can stop plan application when blocking audits fail. The docs describe built-in audits, user-defined audits, and generic audits that return rows when something is wrong.

That makes audits a strong execution path for data contracts. They can prove that a model met nullability, range, accepted-value, uniqueness, and other checks before invalid data moves further downstream.

Executable evidence is not the whole contract

The audit result should become evidence attached to the data product contract. It should say which model ran, which environment was evaluated, which intervals were checked, which audit failed or passed, and whether the result blocked promotion.

The broader contract still needs catalog ownership, lineage, policy context, semantic definitions, freshness expectations, and consumer impact. SQLMesh can run the check. The open infrastructure layer needs to preserve what the check meant.

The ODI pattern

Open Data Infrastructure needs executable controls that travel with data products. A SQLMesh audit can be one such control when it is versioned, reviewed, and connected to the catalog and lineage path.

This matters for AI consumers because agents and evaluation systems need to know whether the data they retrieved came from a product that passed its checks. A green audit should be inspectable context, not a hidden CI detail.

What breaks first

• Audits pass, but nobody records which data product version they validated.
• A failed non-blocking audit is treated as harmless even when an AI consumer depends on that field.
• The contract only checks model output and ignores policy, lineage, or semantic changes.
• Audit definitions drift away from the catalog terms consumers actually use.

Questions to ask

Ask whether each audit maps to a contract promise. Ask whether audit results are tied to environments, intervals, data product versions, and downstream consumers. Ask whether the catalog can expose the latest contract evidence to humans and agents.

For adjacent architecture, read SQLMesh plans as data change control, data product versioning, and semantic contracts in ODI.

Sources to start with

These primary sources anchor the technical claims in this guide.

• SQLMesh auditing documentation
• SQLMesh plans documentation
• OpenLineage documentation
• DataHub documentation

The audit is strongest when it proves a contract the rest of the infrastructure can see.