A data contract holds the specification, governance terms, and access control for a product’s data, and organizes its schema, servers, and supporting elements. See Data contracts for the concepts. This group has seven object types: Data contract, Schema object, Schema property, Server, Schema relationship, Authoritative definition, and Custom property.
Data contract
A data contract is the formal, optional agreement about what a data product delivers. It sets the scope, schema, quality guarantees, commercial terms, and who may access the data. In the Data Product Standard application, the Data contract object type belongs to the Data contract and schema group.
It follows the Open Data Contract Standard (ODCS), so ODCS-compatible tools can read a contract exported from Dawiso. Alongside ODCS, the application implements the Open Data Product Specification (ODPS) for the product and commercial layers. Attach a contract as a data product matures and other teams depend on it. For example, a “Customer 360” product publishes a contract for its orders dataset, served from Snowflake. For what a contract covers, when to attach one, and its lifecycle, see Data contracts.
Data contract attributes
A data contract has the following attributes:
| Attribute | Description |
|---|---|
| Description | Rich-text summary of the contract. |
| ID | Unique contract identifier. |
| Type | Contract standard: odcs or dcs. |
| Version | Contract version. |
| URL | Link to the contract source. |
| Contract Specification | Rich-text or structured contract specification. |
| Purpose | Rich-text statement of what the contract covers. |
| Limitations | Rich-text note on known limitations. |
| Usage | Rich-text guidance on intended usage. |
| Price Amount | Subscription price per unit of measure defined in Price Unit. |
| Price Currency | Currency of the subscription price declared in Price Amount. |
| Price Unit | Unit of measure that Price Amount is charged against. |
| API Version | Version of the contract API. |
| Tenant | Indicates the property / organization / business unit the data is primarily associated with. |
| Tags | Free-text tags for the contract. |
Data contract field reference
The application shows this help text when you create or edit a data contract. It is reproduced here for reference.
Description
The main description of the data contract. Explain what this contract governs, who the parties are, and what commitments it encodes — the high-level overview that sits above the detailed spec (schema, terms, SLA, quality).
Good descriptions answer
- What data product / datasets does this contract cover?
- Who are the producers and consumers?
- What are the headline promises (freshness, availability, quality, support response)?
- Under which license / pricing model is the data delivered?
Best practice
- Keep it short — 2–4 paragraphs. The full terms belong in the Contract Specification (ODCS YAML / JSON).
- Version bumps should reflect changes here: a MINOR version may add a new promise; a MAJOR version reflects a breaking schema or pricing change.
- If the contract is part of a family (e.g. per-consumer-tier contracts under one product), cross-link the siblings here.
Required by the ODPS / ODCS standards. Consumers read this first — make it crystal clear what they’re signing up to.
ID
A unique, stable identifier for this data contract — usually a UUID. Every other system that references the contract (tooling, downstream contracts, lineage, registries) resolves it through this ID.
What to enter
- A stable string; UUID v4 (
53581432-6c55-4ba2-a65f-72344a91553a) is the safest default - Lowercase, URL-safe characters only
- Must be unique across your whole contract catalogue
When to set it
- At creation time, and never change it afterwards — external references break immediately when the ID changes
- Required by ODCS — every data contract must have one.
Best practice
Generate the ID once with a UUID tool, paste it in, and freeze it. Don’t derive it from the contract’s name or version.
Type
Classifies this contract by the standard or format its specification follows. Consumers look at this to know how to read the Contract Specification content.
Values
- ODCS — Bitol Open Data Contract Standard (v3.x, currently recommended)
- DCS — legacy Data Contract Specification
When to set
Pick a type at creation and keep it consistent across all contracts in your catalogue if you can. Switching the type means rewriting the spec.
This field is Dawiso-specific — ODCS itself has a constant kind: DataContract that’s implicit here.
Version
Current version of this specific contract (not of the ODCS standard).
Conventions
Follow semantic versioning: MAJOR.MINOR.PATCH.
- MAJOR — breaking changes to schema or terms
- MINOR — backward-compatible additions (new optional fields, new quality rules)
- PATCH — bug fixes, clarifications, typos
Every change consumers need to know about gets a version bump.
Required by ODCS. Downstream systems may pin to a specific contract version; bumping the major version is the signal that breakage is possible.
URL
Public or internal URL where the canonical, published version of this contract lives — typically a Git repository file, internal wiki page, or documentation portal.
What to enter
- Direct URL to the contract document (YAML / Markdown / HTML)
- Prefer a stable, version-pinned URL (e.g. link to a Git tag, not a branch) — otherwise the link rots on every edit
Related
Contract Specificationholds the spec inline in the catalogueURLpoints to its authoritative external home
Contract Specification
The full text of the contract, pasted inline — usually a YAML document in ODCS format, though JSON or Markdown works too.
What to enter
- The raw contract document, parseable by the standard declared in
Type - ODCS contracts follow the v3.1.0 schema
Related
URLpoints to the canonical published version if the contract is hosted elsewhereAPI Versiondeclares which ODCS revision this spec conforms to
Purpose
Why does this data contract exist? The business outcome or question this data is intended to support.
Write it for
- Consumers evaluating whether this contract matches their needs
- Governance teams reviewing alignment with business goals
Good purpose statements
- “Enable marketing to segment customers for targeted email campaigns.”
- “Provide regulators with audit-ready views of all KYC events.”
- “Power the weekly CFO leadership dashboard with consolidated revenue figures.”
Avoid
- Restating the technical schema (that’s what the Specification is for)
- Vague phrases like “improve data quality” — describe the concrete outcome
Limitations
What this contract does NOT cover. Known scope boundaries, data exclusions, temporal limits, geographic restrictions, accuracy caveats.
Common things to document
- Temporal: “Historical data only back to 2020-01-01.”
- Geographic: “EMEA regions only; APAC excluded.”
- Source coverage: “Does not include B2B transactions.”
- Freshness: “Near-real-time — up to 5-minute lag.”
- Accuracy: “Amounts reconciled to the penny; forex rates refreshed daily.”
Explicit limitations prevent misuse, reduce support requests, and set correct expectations for consumers.
Usage
Guidelines for how consumers should and should not use the data governed by this contract.
Describe
- Allowed use cases — analytics, reporting, ML training, operational decisions, etc.
- Prohibited uses — personal identification, resale, combination with other datasets
- Attribution / licensing notes
- Access patterns expected (read-only, rate limits, batch vs. streaming)
Pairs with Limitations — together they form the “fair use” section of the contract. Consumers agreeing to the contract are agreeing to these usage terms.
Price Amount
Subscription price per unit of measure defined in Price Unit. Numeric; 0 for free contracts.
Examples
100— ifPrice Unitismonth0.001— ifPrice Unitisapi_call5000— ifPrice Unitisyear
When to set
- Only when this contract is commercial (internal or external billing)
- Leave empty for internal-only contracts with no cost attribution
Price Currency
Currency of the subscription price declared in Price Amount. Use the ISO 4217 three-letter code.
Common values
USD— US DollarEUR— EuroGBP— British PoundCZK— Czech KorunaJPY— Japanese Yen
Required whenever Price Amount is set.
Price Unit
Unit of measure that Price Amount is charged against.
Common values
- Time-based —
month,year,day - Volume-based —
gigabyte,terabyte,megabyte - Per-transaction —
api_call,request,row,query - Flat —
contract(one-time fee),seat
Example
Price Amount = 100, Price Currency = USD, Price Unit = month → “100 USD per month”.
API Version
The ODCS specification version this contract conforms to. Default: v3.1.0.
Why it matters
Different ODCS revisions have different fields, enum values, and validation rules. Tooling — including this catalogue and downstream consumers — uses API Version to know how to parse the contract correctly.
Common values
v3.1.0— current (Bitol ODCS 3.1.0)v3.0.2— previous minorv2.x— legacy (pre-Bitol)
Required by ODCS.
Tenant
Indicates the property / organisation / business unit the data is primarily associated with. Case-insensitive.
What to enter
- Tenant identifier (e.g.
acme-retail,emea-finance,climatequantum) - Keep it short and stable — this is often used as a prefix / filter in multi-tenant reporting
When to use
Only relevant when multiple logical tenants share the same Dawiso instance or contract registry. In single-tenant deployments, leave it empty.
Tags
Free-text labels that help users find this contract in the catalogue. Each tag is a short keyword — pick whatever helps search + filtering.
Useful tag dimensions
- Business domain —
sales,customer,finance,hr - Regulatory scope —
gdpr,sox,pii,hipaa - Data freshness —
realtime,daily,monthly,batch - Audience —
internal,external,partner - Criticality —
strategic,experimental,deprecated
Tips
- Lowercase, short, unambiguous
- Reuse existing tags across contracts — otherwise search gets noisy
- Don’t put sensitive data in tags; they’re surfaced everywhere search runs
Schema object
A schema object is a logical dataset or table defined inside a data contract’s schema. It groups related schema properties — the columns or fields — under one named structure.
In the Data Product Standard application, this object type belongs to the Data contract and schema group. It comes from the Open Data Contract Standard (ODCS), the open standard Dawiso data contracts are built on.
Define one schema object for each dataset a contract delivers. For example, a “Customer 360” contract defines an orders schema object and a customers schema object, both served from Snowflake.
Schema object attributes
| Attribute | Description |
|---|---|
| Business Name | Human-readable name of the dataset or table. |
| Physical Name | Physical name in the source system. |
| Physical Type | Physical object type, such as a table or view. |
| Data Granularity | Granularity of the rows in the object. |
| Tags | Free-text tags for the object. |
Schema property
A schema property is a single column or field within a schema object. It records the field’s logical and physical type, its key and constraint flags, its classification, and any transform lineage.
In the Data Product Standard application, this object type belongs to the Data contract and schema group. It comes from the Open Data Contract Standard (ODCS), the open standard Dawiso data contracts are built on.
Define one schema property for each column a dataset exposes. The logical type stays platform-neutral — such as string, integer, or timestamp — while the physical type mirrors the source system. For example, the orders schema object in a “Customer 360” contract has a customer_id property, typed string and marked as required.
Schema property attributes
| Attribute | Description |
|---|---|
| Business Name | Human-readable name of the column or field. |
| Logical Type | Data type: string, date, timestamp, time, number, integer, object, array, or boolean. |
| Logical Type Options | Additional constraints on the logical type. |
| Physical Type | Physical data type in the source system. |
| Physical Name | Physical column name in the source system. |
| Required | Whether a value is mandatory. |
| Unique | Whether values must be unique. |
| Primary Key | Whether the property is part of the primary key. |
| Partitioned | Whether the property is a partition key. |
| Classification | Data classification label. |
| Critical Data Element | Whether the property is a critical data element. |
| Transform Logic | Logic used to derive the property. |
| Examples | Sample values. |
| Tags | Free-text tags for the property. |
Server
A server records where a data contract’s data physically lives and how to connect to it. It captures the platform, host, database, schema, and the other connection details a consumer needs.
In the Data Product Standard application, this object type belongs to the Data contract and schema group. It comes from the Open Data Contract Standard (ODCS), the open standard Dawiso data contracts are built on.
Add a server so consumers know which system serves the data behind a contract. The schema says what the data is; the server says where to reach it. For example, a “Customer 360” contract points to a snowflake server that hosts the orders dataset.
Server attributes
| Attribute | Description |
|---|---|
| Type | Platform, such as postgresql, snowflake, bigquery, databricks, s3, kafka, or custom. |
| Environment | Environment the server belongs to, such as production or staging. |
| Host | Server hostname. |
| Port | Connection port number. |
| Database | Database name. |
| Schema | Schema name. |
| Catalog | Catalog name. |
| Project | Project name (for cloud platforms). |
| Dataset | Dataset name (for cloud platforms). |
| Warehouse | Warehouse name (for cloud platforms). |
| Location | Storage location. |
| Endpoint URL | Connection endpoint. |
| Region | Hosting region. |
Schema relationship
A schema relationship is a foreign-key style link from one schema property to another. It records how one dataset references another inside a data contract.
In the Data Product Standard application, this object type belongs to the Data contract and schema group. It comes from the Open Data Contract Standard (ODCS), the open standard Dawiso data contracts are built on.
Add a relationship to record referential structure, the way a foreign key works in a database. Dawiso stores the link as a foreignKey. For example, the customer_id property in the orders dataset points to the id property of the customers dataset.
Schema relationship attributes
| Attribute | Description |
|---|---|
| From | Source schema property. |
| To | Target schema property. |
| Type | Relationship type: foreignKey. |
Authoritative definition
An authoritative definition links a data contract or one of its fields to the official source that defines its meaning. That source can be a business glossary entry, external documentation, a tutorial, or a code repository.
In the Data Product Standard application, this object type belongs to the Data contract and schema group. It comes from the Open Data Contract Standard (ODCS), the open standard Dawiso data contracts are built on.
Add an authoritative definition when a term or column needs a canonical reference beyond the contract. Each link is typed by what it points to, such as a businessDefinition or an implementation. For example, the customer_id property links to the business glossary entry that defines a customer identifier.
Authoritative definition attributes
| Attribute | Description |
|---|---|
| URL | Link to the authoritative source. |
| Type | Source type: businessDefinition, transformationImplementation, videoTutorial, tutorial, or implementation. |
Custom property
A custom property is a key/value pair that extends a standard data contract element with a field the standard does not define. It lets your organization record extra detail on a contract, schema object, property, or server.
In the Data Product Standard application, this object type belongs to the Data contract and schema group. It comes from the Open Data Contract Standard (ODCS), the open standard Dawiso data contracts are built on.
Add a custom property when a standard element must carry an organization-specific field, such as a cost center or retention period. It stores a property name and its value. For example, a “Customer 360” contract element carries a data_domain property set to sales.
Custom property attributes
| Attribute | Description |
|---|---|
| Property | Custom property name. |
| Value | Custom property value. |
For how these object types connect to each other, see Data product object types and attributes.