Data contracts
A table’s promises, kept in git.
A contract names what a table promises the people who read it: its keys, its checks, how fresh it is, its owner and who depends on it. RunningLake checks it on every change and on every run.
PLANNED
How a contract works
Keys and relationships, declared.
A table’s primary key, its unique keys and its relationships to other tables are declared with it in git. No engine enforces a key on an open table, so each key and relationship is checked every time the table is published.
A change that breaks it waits.
Dropping a column, a key or a check, or loosening how fresh the table must be, is a breaking change. It waits for the owners of what depends on the table, and the person who made the change cannot approve it.
A run that breaks it publishes nothing.
When a run’s output would break the contract, nothing is published and your dashboards keep the last good data. Rows a check sets aside go to the table’s quarantine, beside it, visible to the same people.
A standard in and out.
Contracts import from and export to the Open Data Contract Standard (ODCS), so other tools can read them. Inside RunningLake the contract is a file in git, reviewed like any other change.
What a contract cannot hold
A file you upload, or one promoted into a table, is checked after it lands, so its contract can flag it but cannot hold it back. A commit pushed straight to the branch skips the review a change set gets, and a contract cannot ask anyone about it.