ODCS Validator
Validate Open Data Contract Standard contracts instantly. Paste your YAML or JSON data contract and see exactly which fields pass or fail against the official ODCS JSON Schema.
Auto-validates as you type · Cmd/Ctrl+Enter to validate immediately
Paste an ODCS contract on the left to see validation results here.
How to validate your ODCS contract
Paste or load your contract
Paste a YAML or JSON ODCS data contract into the editor, or use the "Load example" dropdown to try one of the built-in samples.
Instant auto-validation
The validator automatically detects your format and apiVersion, selects the matching ODCS JSON Schema, and runs validation as you type.
Review results
A green banner means your contract is valid. Red errors list each failing field path, the violated rule, and a human-readable message.
What is the Open Data Contract Standard (ODCS)?
The Open Data Contract Standard (ODCS) is an open specification maintained byBitol(LF AI & Data Foundation) that defines how data producers and consumers formally agree on the structure, quality, ownership, and operational expectations of a dataset. An ODCS contract is a machine-readable YAML or JSON file that covers:
- Schema — logical and physical column definitions, data types, primary keys
- Data quality — null checks, row counts, duplicate rules, custom SQL checks
- SLA — latency, availability, retention, update frequency
- Team & Roles — owners, stewards, IAM access roles
- Infrastructure — 30+ server types (Snowflake, BigQuery, Kafka, S3, Postgres, …)
- Pricing — subscription cost per unit for data marketplace use cases
- Support channels — Slack, Teams, email, ticketing
ODCS is platform-agnostic and supported natively by tools like the Data Contract CLI, Databricks Ontos, IBM watsonx, Witboost, and many more. The current version isv3.1.0, released December 2025. Starting with v3.1.0, the JSON Schema enforces strict validation — unknown fields are rejected, encouraging use ofcustomProperties for extensions.
ODCS contract examples
Copy these examples directly into the validator above to see them in action.
Minimal valid ODCS v3.1.0 contract (YAML)
apiVersion: v3.1.0
kind: DataContract
id: 53581432-6c55-4ba2-a65f-72344a91553a
name: orders_v1
version: 1.0.0
status: activeThe five fields marked Required below are the only mandatory ones. All others are optional.
Contract with schema and data quality (YAML)
apiVersion: v3.1.0
kind: DataContract
id: abc123-def456
version: 2.0.0
status: active
schema:
- id: orders_tbl
name: orders
physicalType: table
properties:
- id: order_id_prop
name: order_id
primaryKey: true
primaryKeyPosition: 1
logicalType: string
physicalType: varchar(36)
required: true
quality:
- metric: nullValues
mustBe: 0Minimal valid contract (JSON)
{
"apiVersion": "v3.1.0",
"kind": "DataContract",
"id": "53581432-6c55-4ba2-a65f-72344a91553a",
"version": "1.0.0",
"status": "active"
}Common error: unknown top-level field
apiVersion: v3.1.0
kind: DataContract
id: my-contract
version: 1.0.0
status: active
# ❌ This will fail — ODCS v3.1.0 does not
# allow unknown top-level fields.
# Move it to customProperties instead.
myCustomField: some-valueFix: move to customProperties: [{property: myCustomField, value: some-value}]
ODCS v3.1.0 required fields
These five fields must be present in every ODCS v3.1.0 contract. Everything else is optional.
| Field | Type | Allowed values / example | Description |
|---|---|---|---|
| apiVersion | string | v3.1.0 | Version of the ODCS standard this contract follows. |
| kind | string | DataContract | Must be exactly DataContract. |
| id | string | 53581432-6c55-4ba2-a65f-72344a91553a | Unique identifier (UUID recommended) to avoid name collisions. |
| version | string | 1.0.0 | The contract's own semver version (independent of the standard version). |
| status | string | active · draft · deprecated · retired | Lifecycle status of this contract. |
Commonly used optional fields
| Field | Description |
|---|---|
| name | Human-readable contract name |
| domain | Logical data domain (e.g. finance, commerce) |
| tenant | Organisation or property the data belongs to |
| schema | Array of data objects (tables/topics) and their properties |
| servers | Physical locations: Postgres, BigQuery, Snowflake, Kafka, S3, … |
| slaProperties | Latency, retention, availability, frequency SLA entries |
| team | Named team object with member list (v3.1.0+) |
| roles | IAM roles with access levels and approver chains |
| support | Slack, email, Teams, or ticket support channels |
| price | Data product pricing (priceAmount, priceCurrency, priceUnit) |
| customProperties | Non-standard key/value extensions (required instead of unknown top-level fields) |
| contractCreatedTs | ISO 8601 UTC timestamp of contract creation |
Supported ODCS versions
The validator automatically picks the correct schema based on the apiVersion field in your contract. If the version is unrecognised, validation falls back to the latest schema (v3.1.0).
| apiVersion | Status | Notable changes |
|---|---|---|
| v3.1.0 | Latest | Strict schema, FK relationships, improved library metrics, deprecated fields removed |
| v3.0.2 | Supported | Also has a strict schema variant; backward-compatible with v3.1.0 contracts |
| v3.0.1 | Supported | Validated against v3.0.2 schema (closest match) |
| v3.0.0 | Supported | Major v3 rewrite — objects/properties terminology, complex data structures |
| v2.2.2 / v2.2.1 / v2.2.0 | Legacy | Pre-v3 format, table/column model; validated against v2.2.2 schema |