THE LINUX FOUNDATION PROJECTS
search
News

Bitol Announces ODCS v3.1.0: Stronger, Smarter, and Stricter

By December 7, 2025No Comments

Bitol Announces ODCS v3.1.0: Stronger, Smarter, and Stricter

We are thrilled to announce the release of Open Data Contract Standard (ODCS) version v3.1.0, a significant milestone that brings relationships, stricter validation, richer metadata, and smarter contracts to the data contract ecosystem. This release represents the collective wisdom and collaboration of our global Technical Steering Committee and the broader Bitol community, delivering powerful new capabilities while maintaining complete backward compatibility with v3.0.

We extend our sincere gratitude to the Linux Foundation AI & Data for their unwavering support and governance. As an incubation-level project under LF AI & Data, we benefit from a neutral, collaborative environment that enables true open-source innovation. Their commitment to building open standards for the AI and data community has been instrumental in making ODCS the vendor-neutral, industry-wide standard it is today.

What Makes ODCS v3.1.0 Special

ODCS v3.1.0 is all about maturing the standard without disruption. Unlike major version releases that often introduce breaking changes, v3.1.0 focuses on strengthening the foundation, improving consistency, and enabling new use cases while ensuring that every existing v3.0 contract remains perfectly valid.

The release brings several transformative capabilities:

  • Relationships between properties: Define how data elements relate to each other
  • Stricter JSON Schema validation: Eliminate ambiguity and improve interoperability
  • Enhanced metadata support: Richer descriptions and custom properties throughout
  • Executable SLAs: Schedule and automate service-level agreement checks
  • Improved referencing: Cleaner ways to reference both internal and external contracts
  • Strategic deprecations: Simplify the standard by removing unused elements

Key Enhancements in Detail

RFC-0013: Relationships Between Properties

One of the most requested features is now here: the ability to explicitly describe relationships between properties in your data contracts. RFC-0013 introduces a powerful new capability that lets you define relationships like foreign keys, even when the underlying system doesn’t enforce them.

This opens up exciting possibilities:

  • Automated validation: Tools can verify referential integrity across datasets
  • SQL DDL generation: Generate CREATE TABLE statements with proper foreign key constraints
  • ER diagram generation: Automatically visualize your data model relationships
  • Documentation clarity: Make implicit relationships explicit for data consumers

Example of defining relationships:

schema:
  yaml
schema:
  - id: orders_tbl 
    name: orders
    properties:
      - id: customer_id
        name: customer_id
        logicalType: string
        relationships:
          - type: foreignKey
            to: customers.cust_id # shorthand notation
            description: "Links to the customer who placed the order"
      
      - id: product_id 
        name: product_unique_id
        logicalType: string
        relationships:
          - type: foreignKey
            to: products.prod_id #shorthand notation
            to: schema/products/properties/prod_id #standard notionat

These relationship definitions enable tooling to understand your data model’s structure and constraints, even when working with systems like data lakes or NoSQL databases that don’t enforce referential integrity at the platform level.

For more details, see the RFC-0013 specification.

RFC-0009a & RFC-0009b: Enhanced Contract Referencing

ODCS v3.1.0 introduces two complementary enhancements to how contracts can reference other contracts and internal elements:

RFC-0009a: External Contract References (specification)

Contracts can now reference external contracts using file-based paths, making it easier to compose complex data products from multiple contracts:

schema:
  - name: enriched_orders
    properties:
     - name: enriched_orders
    properties:
      - name: customer_data
        $ref: "./customers.odcs.yaml#/schema/0/properties/0"

RFC-0009b: Internal Reference Shortcuts (specification)

For internal references within the same contract, you can now use intuitive table.column shortcuts:

quality:
  - description: "Validate customer_id exists in customers table"
    element: orders.customer_id
    rule: "EXISTS IN customers.id"

These enhancements make contracts more modular and maintainable, especially in large data platforms with dozens or hundreds of contracts.

RFC-0024: Extensions to Custom Properties and Authoritative Definitions

RFC-0024 brings important alignment between ODCS and ODPS (Open Data Product Standard), adding optional description fields to custom properties and authoritative definitions. This enables richer metadata throughout your contracts:

schema:
  - name: customer_profile
    customProperties:
      - property: dataClassification
        value: PII
        description: "Contains personally identifiable information subject to GDPR"
      - property: retentionPeriod
        value: "7 years"
        description: "Required retention period per financial regulations"
    
    authoritativeDefinitions:
      - type: businessGlossary
        url: "https://glossary.company.com/customer-profile"
        description: "Official business definition from the enterprise glossary"

This alignment ensures that as organizations adopt both ODCS and ODPS, they benefit from consistent metadata patterns across both standards.

RFC-0025: Scheduling SLA Checks

Service-level agreements are only meaningful if they’re monitored and enforced. RFC-0025 introduces the ability to schedule SLA checks alongside data quality rules, making SLAs executable rather than just documentation.

You can now schedule checks for:

  • Latency: Maximum time from data generation to availability
  • Retention: How long data must be kept
  • Availability: Uptime requirements
  • Frequency: Expected update cadence
  • Completeness: Data coverage requirements

Example of scheduled SLA monitoring:

sla:
  properties:
    - property: latency
      value: "4 hours"
      unit: hours
      description: "Data must be available within 4 hours of generation"
      scheduler: cron
      schedule: "0 */2 * * *"  # Check every 2 hours
    
    - property: availability
      value: "99.9"
      unit: percent
      description: "Dataset must be accessible 99.9% of the time"
      scheduler: interval
      schedule: "5m"  # Check every 5 minutes

This makes SLAs first-class citizens in your data contracts, with the same execution semantics as data quality rules. Tools can now automatically monitor and alert on SLA violations.

For implementation details, see the RFC-0025 specification.

RFC-0023: Improved Support Channels

RFC-0023 enhances the support section with several practical improvements:

  • Makes url optional for channels where it’s not applicable
  • Introduces customProperties for channel-specific metadata
  • Adds a new notifications scope for one-way communication
  • Expands suggested tools to include Google Chat

Example of enhanced support channels:

support:
  - channel: "data-contracts-help"
    tool: slack
    scope: interactive
    url: "https://company.slack.com/archives/C05UZRSBKLY"
    description: "Ask questions and get help from the data team"
  
  - channel: "data-contracts-alerts"
    tool: googleChat
    scope: notifications
    url: "https://chat.google.com/room/AAAA..."
    description: "Automated alerts for data quality issues"
  
  - channel: "office-hours"
    tool: zoom
    scope: interactive
    description: "Weekly office hours every Tuesday at 2pm EST"
    customProperties:
      - property: meetingId
        value: "123-456-789"
      - property: passcode
        value: "datacontracts"

These improvements make it easier for data consumers to find the right communication channel for their needs, whether they need interactive help, want to subscribe to notifications, or need to escalate issues.

For complete details, see the RFC-0023 specification.

RFC-0021 & RFC-0022: Deprecation of slaDefaultElement

The slaDefaultElement field, introduced in earlier versions, has proven to be confusing and is rarely used in practice. RFC-0021 and RFC-0022 address this by deprecating the field while ensuring custom properties are available everywhere they’re needed.

The field remains tolerated for backward compatibility, but we recommend using explicit element references or custom properties instead:

# Deprecated approach (still works)
sla:
  slaDefaultElement: my_table
  properties:
    - property: freshness
      value: "24 hours"

# Recommended approach
sla:
  properties:
    - property: freshness
      value: "24 hours"
      element: my_table  # Explicit element reference

Deprecation of dataProduct at Top Level

To clarify the separation of concerns between ODCS (contracts) and ODPS (products), the dataProduct field at the contract’s top level is now deprecated. Data contracts describe individual datasets or APIs, while data products encompass multiple contracts along with additional metadata.

Organizations using ODPS should define the data product structure in their ODPS files, which can then reference multiple ODCS contracts. This architectural clarity makes it easier to manage complex data platforms where a single data product might include multiple contracts.

For more information about data products, see the Open Data Product Standard (ODPS) v1.0.0 release.

Strict JSON Schema: The Most Important Change

The most transformative change in v3.1.0 is the introduction of strict JSON Schema validation. In previous versions, ODCS tolerated additional fields that weren’t formally defined in the schema. While this provided flexibility, it also led to inconsistency across tools and implementations.

With v3.1.0, ODCS adopts a strict validation approach:

  • No undefined fields: Only fields defined in the JSON Schema are allowed
  • Consistent validation: All tools interpret contracts identically
  • Better error messages: Validators can provide specific feedback on schema violations
  • Improved interoperability: Contracts work seamlessly across different platforms

This change doesn’t break existing contracts—any field you were using in v3.0 that was part of the official schema continues to work. What changes is that custom additions outside the schema will now be flagged as errors, encouraging proper use of customProperties for extensions.

To validate your contracts against the strict schema, use the official JSON Schema:

# Using a JSON Schema validator
yajsv -s odcs-json-schema-v3.1.0.json your-contract.odcs.yaml

Many IDEs, including VS Code and IntelliJ, will automatically validate your contracts if you use the .odcs.yaml file extension, thanks to our integration with SchemaStore.

No Breaking Changes

We want to emphasize that ODCS v3.1.0 includes zero breaking changes. Every contract that validates against v3.0.2 will continue to validate against v3.1.0. This commitment to backward compatibility means you can upgrade with confidence.

The deprecations introduced in this release (slaDefaultElement and top-level dataProduct) remain fully functional. They generate warnings rather than errors, giving organizations time to migrate at their own pace.

Migration and Adoption

Upgrading from v3.0

Upgrading from v3.0.x to v3.1.0 is straightforward:

  1. Update the apiVersion in your contracts from v3.0.2 to v3.1.0
  2. Validate your contracts with the new strict schema
  3. Address any validation warnings about deprecated fields
  4. Optionally adopt new features like relationships and scheduled SLAs

Tooling Support

Several vendors in the Bitol ecosystem are already working on v3.1.0 support:

Check the vendors page for the latest tool support information.

Validation and Schema

The complete JSON Schema for v3.1.0 is available in our repository:

The official media type for ODCS v3.1.0 is:

application/odcs+yaml;version=3.1.0

Examples and Documentation

We’ve added numerous examples demonstrating the new v3.1.0 features:

Complete documentation is available at our documentation site.

RFC Process and Community Development

ODCS v3.1.0 demonstrates the power of our open RFC process. All approved RFCs for this release are available in the TSC repository:

Each RFC went through community review, discussion, and iteration before being approved by the Technical Steering Committee. This transparent process ensures that every feature addresses real-world needs and has broad support.

Active RFCs under development for future releases include:

We encourage everyone to participate in RFC discussions, propose new features, and help shape the future of ODCS.

What’s Next: Looking Ahead to v3.2 and Beyond

The community is already hard at work on future enhancements. Some exciting initiatives on the horizon include:

Implicit Data Quality Rules (RFC-0012)

We’re building a library of common data quality rules that can be referenced by name rather than requiring custom SQL or tool-specific syntax. This will make it dramatically easier to define standard checks like uniqueness, completeness, freshness, and format validation.

Enhanced Lineage (RFC-0011)

Future versions will include comprehensive lineage capabilities that describe how data flows through transformations, pipelines, and systems. This will enable automated lineage visualization and impact analysis.

Business Rules (RFC-0008)

Business rules support will allow you to document the business logic and calculations embedded in your data, making contracts even more valuable as documentation.

Integration with ODPS

As the Open Data Product Standard (ODPS) v1.0.0 matures, we’re working on tighter integration patterns between the two standards, including standardized ways for ODPS files to reference ODCS contracts.

Getting Started with ODCS v3.1.0

Ready to adopt ODCS v3.1.0? Here’s how to get started:

1. Read the Documentation

Visit our documentation site for comprehensive guides and reference materials.

2. Explore Examples

Browse our examples repository to see real-world implementations of all v3.1.0 features.

3. Validate Your Contracts

Download the JSON Schema and integrate it into your development workflow. Use the .odcs.yaml file extension for automatic IDE validation.

4. Try Interactive Tools

Use the Data Contract Playground to create and validate contracts interactively without any setup.

5. Review the Changelog

Check the detailed changelog for a complete list of changes, enhancements, and fixes.

6. Join the Community

Connect with other ODCS users and contributors:

  • Slack: Join our channels in the Data Mesh Learning community
  • GitHub: Star and watch our repository for updates
  • TSC Meetings: Monthly Technical Steering Committee meetings are open to observers
  • Working Groups: Join active working groups on specific RFCs

Contributing to ODCS

Bitol thrives on community contributions. Whether you’re a data engineer, architect, analyst, or tool vendor, there are many ways to contribute:

Share Your Contracts

Submit example contracts from your organization via pull requests. Real-world examples help others understand how to apply ODCS effectively.

Propose Enhancements

Have an idea for improving ODCS? Create an RFC in our TSC repository. The RFC process is open to everyone.

Improve Documentation

Help us make ODCS more accessible by improving documentation, creating tutorials, or translating materials into other languages.

Build Tools

Create tools, libraries, or integrations that support ODCS. Add them to our vendors page.

Report Issues

Found a bug or unclear documentation? Open an issue in our GitHub repository.

Join the TSC

The Technical Steering Committee is always looking for engaged community members. If you’re interested in deeper involvement in governance, reach out to learn about joining.

Acknowledgments

ODCS v3.1.0 represents the hard work and dedication of many individuals and organizations. We want to specifically thank our Technical Steering Committee members for their leadership: Andrea Gioia (Quantyca), Andrew Jones (Springer Nature), Andy Petrella (NextLab), Atanas Iliev (ALH Gruppe), Christian Foyer (Systematic), Diego Carvallo (Pickle), Dirk Van de Poel (Klarrio), Gene Stakhov (enChoice), Jochen Christ (Entropy Data), Manuel Destouesse (Pyxus Intl.), Martin Meermeyer (Lidl e-commerce), Peter Flook (Data Catering), Simon Harrer (Entropy Data), Tom De Wolf (ACA Group), and Jean-Georges Perrin (Actian, Chair).

We also thank the dozens of community contributors who participated in RFC discussions, submitted issues, and helped test pre-release versions.

Finally, our deepest appreciation goes to Linux Foundation AI & Data for providing the governance structure, neutral ground, and infrastructure that makes this collaborative work possible. Their commitment to open standards and open source aligns perfectly with our mission to create vendor-neutral standards that serve the entire data community.

Quick Reference

Current Version: v3.1.0
Release Date: December 2025
License: Apache 2.0
API Version: v3.1.0
Media Type: application/odcs+yaml;version=3.1.0

Key Links:

Citation:

@manual{ODCS2025,
  title = {Open Data Contract Standard (ODCS)},
  author = {{Bitol}},
  organization = {LF AI & Data Foundation},
  version = {3.1.0},
  year = {2025},
  url = {https://bitol-io.github.io/open-data-contract-standard}
}

Together, we’re building the foundation for the next generation of data contracts. Join us in making ODCS the standard that powers trustworthy, well-governed data ecosystems worldwide.

Website: bitol.io
Twitter: @BitolIO
LinkedIn: Bitol Organization

ilieff

About ilieff