Who Owns Metadata? Authority, Accountability and the Operating Model

Understanding Metadata Systems

This article is part of a series exploring metadata systems from first principles—from why metadata exists to how modern metadata platforms are designed, implemented and operated.

Previous: Why a Metadata Platform? When Distributed Knowledge Stops Scaling

In the previous article, we explored why organizations may need a shared metadata platform as their data landscape grows.

Metadata may already exist across databases, warehouses, pipelines, governance systems and domain teams. The problem begins when consumers can no longer easily discover, assemble and combine that distributed knowledge efficiently.

A metadata platform helps bring this knowledge together.

But that creates another question:

If metadata from many systems and teams is brought together into a shared platform, who actually owns it?

At first, the answer may appear simple: perhaps the team that owns the dataset owns its metadata.

But when we look more closely, the answer becomes more interesting.

One Data Asset, Many Kinds of Knowledge

Let us return to our customer_orders dataset.

A metadata platform might show something like this:

customer_orders
Description:      Customer orders placed through commerce channels
Owner:            Commerce Team
Schema:           customer_id STRING
                  price DECIMAL(10,2)
Classification:   customer_id → PII
Freshness:        15 minutes
Quality:          PASS
Lineage:          order_service → customer_orders → sales_dashboard

To a consumer, this appears as one data asset with one collection of metadata.

But where did all this knowledge come from?

• The database or warehouse knows the physical schema.
• The Commerce domain understands what the dataset means.
• Security or governance determines whether information should be classified as sensitive.
• A data-quality system evaluates quality rules.
• The pipeline or orchestrator knows when processing last completed.
• Transformation and processing systems may provide information about lineage.

So although the metadata platform presents a unified view, the knowledge represented by that view may originate from several different authorities.

This makes the question “Who owns the metadata?” too broad.

A more useful question is:

Who is authoritative for each kind of knowledge about the data asset?

Ownership, Authority and Permission Are Different

This distinction becomes easier if we separate three concepts that are often treated as though they mean the same thing:

Ownership, Authority and Permission.

Ownership

Ownership is primarily about accountability.

Who is responsible for the data asset or a particular area of metadata?

For example, the Commerce team may own customer_orders and be accountable for ensuring that consumers understand its intended business use.

Authority

Authority answers a different question:

Who or what can reliably determine a particular fact?

• The warehouse may be authoritative for the physical column type.
• The Commerce domain may be authoritative for the business definition.
• Security or governance may be authoritative for the classification.
• The orchestrator may be authoritative for the last successful pipeline execution.

There does not need to be one authority for every piece of metadata about an asset.

Permission

Permission is about technical access.

Who is allowed to read or modify something?

• A metadata-platform administrator might technically have permission to change a business description.
• That does not necessarily mean the administrator has the authority to decide what that business description should say.
• Similarly, a domain team may own a dataset while Security remains authoritative for its security classification.

Therefore:

• Ownership tells us who is accountable.
• Authority tells us who can determine the fact.
• Permission tells us who is technically allowed to act on it.

These concepts may overlap, but they are not the same.

Bringing Metadata Together Does Not Transfer Authority

Now consider what happens when metadata is brought into a shared platform.

Suppose a warehouse reports:

price → DECIMAL(10,2)

The metadata platform collects this information and displays it.

Has the metadata platform now become authoritative for the physical type of price?…..No.

The warehouse remains authoritative for its schema. The metadata platform is representing knowledge obtained from that source.

The same principle applies to business meaning.

Suppose the Commerce domain defines:

price = unit selling price after discount and before tax

The metadata platform may store and expose this definition to thousands of consumers.

But storing the definition does not transfer business authority from the Commerce domain to the platform team.

Likewise:

Warehouse            → Physical schema
Commerce Domain       → Business meaning
Security/Governance   → Classification
Data Quality System   → Quality status
Orchestrator          → Operational freshness
             ↓
       Metadata Platform

The platform provides a shared representation of knowledge whose authority may remain distributed.

This gives us an important architectural principle:

Centralizing access to knowledge does not automatically centralize authority over that knowledge.

What Happens When Sources Disagree?

Distributed authority works neatly when every source provides compatible information.

Real systems are rarely that simple.

Imagine that our metadata platform receives the following information:

Commerce documentation:
customer_id → Internal customer identifier
Security classification:
customer_id → PII
Warehouse:
customer_id → STRING

There is no real conflict here.

Each source is describing a different characteristic of the same field.

But now imagine something different.

A domain document says:

customer_id → Non-sensitive internal identifier

While the security-governance process classifies it as:

customer_id → PII

Which value should the metadata platform show?

It would be dangerous to resolve this simply according to whichever system updated the metadata most recently.

The question is not:

Which source wrote last?

The question is:

Which source has authority to determine this particular fact?

• For a security classification, the governance or security process may have authority.
• For a physical column type, the warehouse may have authority.
• For a business definition, the relevant business domain may have authority.

This means a metadata platform eventually needs more than the ability to collect metadata.

The organization also needs rules defining which systems or roles are authoritative for which kinds of metadata and what happens when information conflicts.

At that point, the problem is no longer purely technical.

It becomes an operating-model problem.

So What Does the Metadata Platform Team Own?

If authority remains distributed, does the metadata-platform team own anything?

Absolutely.

But it owns a different layer of responsibility.

The platform team may be accountable for capabilities such as:

• Svailability and reliability of the metadata platform;
• Metadata integration mechanisms;
• APIs and search capabilities;
• Authentication and authorization controls;
• Platform observability;
• Metadata-model capabilities;
• Upgrades and lifecycle management;
• Operational support.

The platform team therefore owns the technical capability through which metadata is integrated and consumed.

But it does not automatically become responsible for deciding every fact represented by the platform.

For example, the platform team should not decide what net revenue means simply because the definition is stored in its database.

Nor should it independently decide whether a customer identifier is PII merely because it operates the platform exposing that classification.

This distinction is important:

The platform team can own the metadata platform without owning all the metadata represented by the platform.

Shared Platform, Distributed Responsibility

We can now see an operating model beginning to emerge.

Different participants have different responsibilities.

This is not necessarily a choice between completely centralized and completely decentralized metadata management.

A shared technical platform can coexist with distributed responsibility.

The platform provides common capabilities for discovery, representation and consumption, while domains and specialist functions retain authority over the knowledge they are best positioned to determine.

In other words:

This is why metadata architecture cannot be solved only by deploying a catalog or metadata product.

The technology may bring knowledge together.

The operating model determines who is responsible for keeping that knowledge meaningful and trustworthy.

Metadata Ownership Is Not One Question

We started with what appeared to be a simple question:

Who owns the metadata?

But that question hides several different questions:

• Who owns the underlying data asset?
• Who is accountable for its business meaning?
• Which system is authoritative for its technical state?
• Who determines its security classification?
• Who is allowed to modify each kind of metadata?
• Who operates the platform through which that metadata is discovered?
• And what happens when two sources disagree?

There may therefore be no single answer to “Who owns the metadata?”

A better architecture starts by asking:

Who is accountable for each kind of knowledge, which source is authoritative for it, and who should have permission to change it?

Once those responsibilities are clear, the shared metadata platform has a much stronger foundation.

But this leads to another problem.

We now have datasets, pipelines, dashboards, domains, schemas, owners, classifications and relationships—all different kinds of things and knowledge that our metadata platform somehow needs to represent consistently.

So how should we model them?

That takes us to the next article.

Continue the Series

Previous: Why a Metadata Platform? When Distributed Knowledge Stops Scaling

Next: Modelling Metadata: From Data Assets to Entities, Identity and Relationships — Coming soon