Data contracts

A data contract bundles a schema definition and a set of checks into one named, versioned object — something you can hand to a downstream consumer as a promise about a table's shape and quality, and validate against a real connection before trusting it.

Structure

Object	Holds	Notes
Contract	A name and description	The container — versions live under it
Contract version	A version_tag, a schema definition, and a checks definition	Immutable once created; make a new version to change either

A version's schema definition is a list of columns, each with a name and type:

{
  "columns": [
    { "name": "order_id", "type": "uuid" },
    { "name": "customer_id", "type": "uuid" },
    { "name": "total_amount", "type": "decimal" },
    { "name": "created_at", "type": "timestamp" }
  ]
}

A version's checks definition is a list of check definitions — the same shape used in YAML check files, just embedded directly in the contract rather than loaded from a file:

[
  { "name": "no_null_order_id", "check_type": "null", "table_name": "orders", "column_name": "order_id" },
  { "name": "positive_total", "check_type": "numeric_non_negative", "table_name": "orders", "column_name": "total_amount" }
]

Validating a table against a contract

In the Contracts screen, open a contract version and choose Validate, then pick a connection and the table you want to check it against. CatalystData runs the version's checks definition against that table and returns a summary — total checks, passed, failed, errors, warnings — without persisting the results as check runs. This is meant for a quick "does this table still match the contract" question, not for ongoing monitoring; for that, turn the same checks into real scheduled checks on the connection.

When to use a contract instead of ad hoc checks

• You want one version-controlled object that describes both the expected shape and the expected quality of a table, for example to hand to a team consuming data you produce.
• You want to validate a table on demand — before a migration, before promoting a new load — without needing a schedule.
• You want a history of what "acceptable" meant at each version, not just the current set of checks.

For checks that should simply run on a schedule and alert on failure, adding them directly under a connection (see Your first connection and check) is simpler and is what schedules and alert rules attach to.