The 4 Principles of Data Ownership

Data ownership is probably the most unsolved problem in data management. Let's solve it.

Only data that someone feels responsible for is data we can build our business processes and decisions on. This someone cleans up inconsistencies and ensures the data is complete. This someone makes sure that all pipelines are green. This someone cares about good documentation. This someone is someone you can talk to when you have questions. And this someone earns the credit for the value others create with their data.

Are you this someone?

Congratulations. You are doing a great job. But let's be honest: there is so much more data in your organization where this someone is missing, or where you don't know whether there is someone at all.

Of course, it is all about ownership. Ownership of data is challenging. But luckily, today we have methods and tools that can help.

The 4 Principles of Data Ownership

There are a few principles that we found useful when discussing data ownership:

OK, let's look at what we mean by that:

You Build It, You Own It

When data enters your domain, you become the owner. You define the form input fields, you build the APIs, you control the inbound pipeline. You know what a status enum means. You know the meaning of the six different timestamp columns. You know what happens in error and edge cases. You build the system, so it is your data. It is your job to know that. You are the data owner. No excuses.

We typically recommend team ownership, not individual persons. This avoids hassle when someone is on leave or when team staffing changes. In some organizations, we see a split into IT teams and business teams. Here, we recommend that the team that works most with the data takes the primary ownership role: for source-aligned data products, this is often the IT team; for consumer-aligned data products, it is often the business team or a proxy team.

Publish Data Products

We have all looked into the enterprise data catalogs (Collibra, Informatica, DataHub, you name it), and after seeing the number of automatically indexed data assets (like 2,321,021 tables and files) and the very technical details (serialization, file formats, and encodings), it becomes very clear that these automatically crawled assets do not help with taking ownership. Too technical and too many.

So let's introduce data products. While it is difficult to find a generic definition for a data product (is it a table, a schema, a Power BI semantic model, a Kafka topic, an API, a dbt project, ...), let's focus on value: some data someone wants to use. That someone could be you or your team. It could be another business unit. And it could be an AI agent.

The important thing about data products is: data only becomes a data product if someone takes the ownership role for this data. There is no data product without an owner. Period.

This also means: in enterprises, we do not have millions of data products. Typically, we only have a few hundred data products. Less is better: we get a manageable number of objects that owners can handle and curate.

To make data products findable by others, the owner actively publishes them into a curated data product marketplace, not a technical data asset catalog.

Enforce Data Contracts

Now, let's talk about data contracts. Data contracts specify what a data consumer (again, a person or an agent) can expect from consuming the data. They are the APIs of the data product.

This is:

• Terms of use
• Schema
• Semantics
• Data quality
• SLAs
• Endpoints

The terms of use include the business description, the purpose of the data, the acceptable usage, and the limitations from a technical, compliance, and data governance point of view. With agentic use cases, this is extremely helpful to tell AI agents which data products they might want to use for specific tasks and in which contexts this data is relevant.

The schema includes the structure of the tables and columns, and also logical and governance details, such as data classifications, PII markers, semantic descriptions, example data, and data lineage.

Tables and columns can also be linked to a conceptual business data model or industry standards to add semantic information, forming a full knowledge graph to find related data (again, super useful for agentic use cases).

Data quality rules and SLAs define data guarantees and business expectations, such as non-null requirements, row-level rules, valid value ranges, freshness, etc. Quality engines can read these rules, connect to the database endpoints, and validate the data. An open-source data quality engine is the Data Contract CLI.

There is an industry standard: the Open Data Contract Standard (ODCS), managed by Bitol, a Linux Foundation AI & Data project. ODCS defines a YAML format for data contracts. Here is a compact example:

apiVersion: v3.1.0
kind: DataContract
id: orders
name: Orders
version: 1.0.0
status: active
description:
  purpose: Order data for analytics, reporting, and AI use cases.
  usage: Analyze order volumes and revenue, build dashboards, train forecasting models.
  limitations: Not suitable for real-time use cases. Contains PII, do not use for marketing without consent.
schema:
  - name: orders
    physicalType: TABLE
    description: One row per order. Includes successful and cancelled orders.
    properties:
      - name: order_id
        logicalType: string
        description: Internal order ID. Do not show this to a customer.
        primaryKey: true
        required: true
        unique: true
        examples:
          - 99e8bb10-3785-4634-9664-8dc79eb69d43
      - name: order_timestamp
        logicalType: timestamp
        description: The time when the order payment was successfully confirmed.
        required: true
      - name: order_total
        logicalType: integer
        description: The order total amount in cents, including tax, after discounts.
        required: true
        quality:
          - type: library
            metric: nullValues
            mustBe: 0
    quality:
      - type: library
        metric: rowCount
        mustBeGreaterThan: 100000
        description: If there are less than 100k rows, something is wrong.
slaProperties:
  - property: freshness
    value: "24"
    unit: hours
    description: New orders are available within 24 hours.
team:
  name: sales
  description: This data product is owned by the "Sales" team
servers:
  - server: production
    type: snowflake
    account: my-account
    database: sales
    schema: dp_orders_v1

A data contract can be defined for an existing dataset. Or it can be written contract-first to define the requirements for a new data product before any data exists. Very powerful. But both ways are fine.

Now, who is responsible for the data contract? Typically, the data product owner owns the data contract for their data product. But specifying the contract can be a collaborative effort: have a workshop with your data consumers and discuss their data expectations, field by field. And write down what the domain experts discuss: this is the semantics you want to capture.

Be Your First Customer

OK, now we know how to specify data products with data contracts. But the core question is still open: why should anyone take the ownership role for a data product?

Well, one answer is: because your boss tells you to do so. And this is fair enough. Management support and attention are an important part of the adoption process.

But let's also discuss intrinsic motivation: purpose. What is the purpose your data product could provide for you? Yes. Let's build the first data product for your own team with your own domain data, with a nice dashboard. So you can make better decisions and build great AI features in your domain. Connect Claude with your data product to chat with your data. Build an agentic loop with your data to get a Slack message when something meaningful happens in your app.

You get the idea. Build a data product for yourself to generate value. This is a great purpose! Iterate until you are happy. When you are proud of it, publish it to the data product marketplace for others. Earn fame and social rewards. Your data product provides value for your business. Helping others is also a great purpose.

Tools That Help

There are a few tools that help you with taking ownership.

First, to specify the data product, two tools are interesting:

ODCS Excel Template. Yes, use Excel to draft a data contract. It is probably the tool with the best user experience for business users. Send it via email to others and iterate. When you are happy, use the Data Contract CLI converter to convert to and from YAML.

Data Contract Editor. If you prefer a web editor, use the open-source Data Contract Editor, which also brings a visual entity-relationship diagram editor, form-based fields for all ODCS properties, and linting. Fully customizable for custom properties and sections.

Data Product Builder. To implement the data product, use coding agents, such as Claude Code and OpenAI Codex. The data contract tells them what to build. Skills describe how, according to your organization's tech stack and data governance policies. A data product marketplace tells them which upstream data products to use. Once you have the data contract, implementing a compliant data product just takes a few minutes.

Data Contract CLI. To test that the data product you have implemented is in line with the specification and promises of the data contract, use the open-source tool Data Contract CLI. Integrate it into your Airflow, GitHub Actions, Databricks Jobs, etc. to verify that your data product always delivers the promised data quality.

Entropy Data. Our commercial tool that brings all of those tools together to support data product owners in taking their ownership role seriously. Entropy Data also provides a vendor-neutral data product marketplace in an easy-to-use web application.

Start for Free, or explore the interactive demo.