A data contract is a formal agreement about what a data product delivers: its scope, schema, quality guarantees, commercial terms, and who may access it. Contracts are optional, but strongly recommended for any product that other teams depend on in production.
This page covers what a contract contains, the schema it describes, when to attach one to a product, the access and support details it carries, and the lifecycle it follows.
What a data contract contains
A data contract records the agreement itself — its identity, its terms, and the fields that let a producer and a consumer reference the same version of the same document.
| Field | Description |
|---|---|
| Contract ID | Stable identifier — a UUID that never changes. The literal key contract_id is required by the Open Data Contract Standard (ODCS); it identifies the contract even as its content and version evolve. |
| Contract type | The standard the contract follows: ODCS or DCS. |
| Version | A semantic version (such as 1.2.0) that increments as the agreement changes. |
| Published URL | The canonical URL where the contract is published for consumers to read. |
| Purpose | Why the contract exists and what agreement it captures. |
| Limitations | What the contract does not cover, so consumers know its boundaries. |
| Usage | How the data is intended to be used. |
| Pricing | A quick-reference summary of cost, for consumers comparing products. |
The contract’s API version — the ODCS schema version it conforms to — defaults to v3.1.0.
Schema objects and properties
A contract describes the structure of the delivered data through ODCS schema objects and properties. A schema object is a logical dataset or table; a schema property is a column or field within it. Together they tell a consumer what datasets exist, which fields they contain, and how those fields are typed — before a single row is read.
A schema property carries a logical type and a physical type that mirrors the underlying system. The logical type is one of eight values: String, Date, Timestamp, Number, Integer, Object, Array, or Boolean. Each property also carries flags: whether it is required, unique, a primary key, or partitioned, its classification, and whether it is a critical data element. A property can record the transform lineage that produced its value.
| Element | What it describes |
|---|---|
| Schema object | A logical dataset or table within the product. |
| Schema property | A column or field inside a schema object. |
| Schema relationship | A foreign-key-style link from one property to another. |
| Server | The physical location and connection details — type, host, database, schema, catalog, and similar. |
| Authoritative definition | A link to an external, authoritative description of the element. |
| Custom property | An additional, user-defined property carried on an element. |
For the full attribute list on each of these object types, see Data product object types and attributes.
When to attach a data contract
Contracts are optional by design, which supports progressive governance. Start by connecting products with lineage alone, then add a contract as a product matures — typically as it approaches Production and other teams begin to depend on it.
A contract sits between a producer and its consumers. The producer attaches it to an output port — the interface that publishes the data — and every consumer that reads through a matching input port is bound by the same terms. For how ports serve as a product’s interfaces, see Data product ports.
Dawiso supports three governance levels, depending on how much you connect:
| Level | What you connect | What it gives you |
|---|---|---|
| Level 1 | Output port to input port | Lineage only — the data flow is visible, with no formal agreement. |
| Level 2 | Output port to data contract to input port | Governed exchange — the consumer relies on the contract’s schema and terms. |
| Level 3 | A direct port link and a data contract | Both the direct data flow and the governance link, side by side. |
Attachment follows a few rules:
- One output port has at most one data contract.
- One data contract can govern many ports.
- A contract can live at the domain level — a shared agreement used across products — or at the product level, specific to one product.
Informal sharing within a single team needs no contract. Attach one when data crosses departments, goes to external consumers, is regulated, or is paid for.
Roles and support channels
A data contract carries its own access controls and help routes, separate from the product’s descriptive metadata.
Access roles on a contract define who can use the data. Each role records these attributes:
| Attribute | Description |
|---|---|
| Role name | The name of the role. |
| Access granted | The access the role grants. |
| First-level approvers | Who signs off first when a consumer requests that access. |
| Second-level approvers | Who signs off second when a consumer requests that access. |
Support channels tell consumers where to get help with the data. Each channel records these attributes:
| Attribute | Description |
|---|---|
| Channel | The name of the support channel. |
| URL | A link to the channel. |
| Tool | The tool the channel uses. |
| Scope | The scope the channel covers. |
Ownership roles and contract roles are separate. Ownership roles on the product describe accountability — who is responsible for the product. Contract roles describe access — who may consume the data under the agreement.
The data contract lifecycle
A data contract moves through its own workflow states, independent of the product’s lifecycle. Only a contract in the Active state is the enforceable version; the other states record where the agreement sits in its life.
| State | Meaning |
|---|---|
Proposed | The contract has been suggested but not yet drafted. |
Draft | The contract is being written or negotiated with consumers. |
Active | The contract is in force — the enforceable version consumers rely on. |
Deprecated | The contract is being phased out, usually with a replacement available. |
Retired | The contract is no longer in use. |
A Steward approves a contract before it becomes Active — the same sign-off that confirms the producer’s promise meets what consumers need.
Because the two workflows are independent, a product can be in Production while a new contract is still in Draft — for instance, while its terms are negotiated with a new consumer.
Contracts and the open standard
A data contract in Dawiso maps directly to ODCS. Its fields, schema objects, and roles all have ODCS equivalents, so a contract can be exported to standard ODCS format and read by any tool that supports it. For what each open standard contributes, see Built on open standards.
A contract is where a data product’s guarantees live. It can reference specific data quality checks and service-level agreements (SLAs) — see Data quality and SLAs for what those guarantees cover. Without a contract, a cross-team dependency has no agreed schema or terms to hold either the producer or the consumer to.