From Catalog to Value Graph: Why ODPC and ODPG Belong Together

The Shift From Organized Inventory to Connected Business Meaning

Most organizations do not suffer from too few data products; the deeper challenge usually appears when teams cannot explain how those products connect to use cases, strategic objectives, business KPIs, governance expectations, operational signals, and measurable outcomes.

A catalog can organize data products, describe ownership, support discovery, classify domains, and help teams understand what exists across the portfolio, yet the catalog alone does not always explain why a product matters, which business decision it supports, which objective it contributes to, or which signals indicate that its value is increasing or its risk is growing.

This is why the move from catalog to value graph is becoming important for organizations that want to manage data products as business capabilities rather than technical assets.

Why Catalogs Are Still the Foundation

A data product catalog plays a critical role by providing the organization with a structured way to discover, describe, classify, and manage data products across teams, domains, platforms, and business functions.

Without a catalog, data product management often relies on manual discovery, repeated explanations, disconnected documents, internal memory, and informal knowledge that weakens every time ownership changes or the portfolio grows.

ODPC provides this catalog layer by giving organizations a structured way to organize data products and related catalog objects, helping teams move away from scattered descriptions and toward a shared portfolio view that is understood by business users, product managers, data teams, governance teams, and AI systems.

However, once the organization can discover the product, the next set of questions becomes more strategic and more difficult to answer through catalog metadata alone.

The Questions a Catalog Cannot Fully Answer Alone

Once a data product is identified, business and governance teams usually need to ask deeper questions about its purpose, dependencies, value, accountability, and impact.

They need to know which use cases depend on the product, which business objective each use case supports, which KPIs are influenced by the product, which policy governs its use, which stakeholder owns the outcome, and which operational signals indicate that the product warrants more investment or closer governance.

A product may be well-documented in a catalog but still disconnected from the business objectives it supports.

A use case may be listed as important, but still not connected to the products that enable it.

A KPI may be tracked across dashboards, but still not connected to the products that influence its movement.

A signal may indicate demand, risk, quality degradation, adoption growth, or business opportunity, but still remain isolated from the products, objectives, and decisions it should affect.

This is the point where the organization needs more than a catalog structure, because it needs a relationship model that explains how the portfolio creates business value.

Why ODPG Extends the Conversation

ODPG changes the conversation by moving from a list of cataloged products to a connected graph of value, where data products, use cases, business objectives, KPIs, policies, signals, risks, dependencies, and stakeholders can be represented as connected objects rather than isolated records.

A graph helps the organization ask better questions because it not only describes what exists, but also explains how things relate, how value flows, where dependencies exist, where risks appear, and where opportunities may be emerging.

This matters because business value rarely resides in a single object.

Business value usually manifests through the relationship among a data product, the use case that consumes it, the objective that justifies it, the KPI that measures it, the policy that governs it, and the signal indicating whether it is becoming more important.

ODPG makes these relationships explicit, queryable, explainable, and reusable.

How ODPC and ODPG Work Together

ODPC and ODPG should not be seen as competing standards because they address different aspects of the same data product management problem.

ODPC helps organize the portfolio by giving structure to products, domains, references, ownership, and catalog-level information, while ODPG helps explain the portfolio by connecting those objects to value, impact, governance, dependencies, and strategic context.

The catalog helps people and systems discover the data product.

The graph helps people and systems understand why the data product matters.

The catalog helps answer where the product is, who owns it, and how it is described.

The graph helps answer which use case it supports, which objective it contributes to, which KPI it influences, which policy applies to it, and which signal suggests that action may be needed.

Together, ODPC and ODPG create a stronger foundation for managing data products as a portfolio of business value rather than as a collection of documented assets.

A Simple Example of a Catalog to Graph

Imagine an aviation organization with several data products, such as Aircraft Maintenance Events, Flight Delay Patterns, Fleet Availability Metrics, and Spare Parts Inventory.

In an ODPC catalog, each product can be described with its owner, domain, lifecycle state, access method, quality expectations, documentation, and discovery metadata, which gives the organization a clear and structured inventory of the aviation data product portfolio.

In an ODPG value graph, Aircraft Maintenance Events and Spare Parts Inventory can be connected to a Predictive Maintenance use case, which can then be connected to a business objective such as Increase Fleet Availability, which can then be measured by KPIs such as aircraft availability rate, maintenance turnaround time, delay reduction, and operational cost impact.

The same graph can also connect signals such as repeated fault patterns, spare part shortages, maintenance delays, or increased access demand to an opportunity around operational resilience or predictive maintenance optimization.

This is the difference between knowing that products exist and understanding how those products contribute to measurable business outcomes.

Why This Matters for AI Agents and Context Engineering

The move from catalog to graph is also important because AI agents need more than access to data, since they need structured context that explains identity, meaning, ownership, relationships, constraints, quality, governance, and value.

An AI agent that only reads catalog metadata may know that a data product exists, but it may not understand which objective the product supports, which KPI it influences, which policy limits its use, which downstream use cases depend on it, or which signal should trigger a recommendation.

When ODPC and ODPG work together, the agent can use the catalog as the structured entry point and the graph as the relationship layer that supports safer reasoning, better recommendations, and clearer explanations.

This is where data product management becomes more useful for AI, because the organization is no longer only documenting assets, but also providing machine-readable context about how value, governance, and accountability connect.

Possible Relationships to Include in the Value Graph

A stronger ODPC and ODPG model can include relationships that help organizations understand value, reuse, governance, impact, accountability, and dependencies across the data product portfolio.

These relationships matter because they help the organization move from passive documentation to active portfolio intelligence, enabling decisions based on connected context rather than isolated metadata.

The Bigger Point for Data Product Leaders

The future of data product management is not only about creating better catalogs, because the real opportunity is to connect cataloged products to business value, governance logic, operational signals, and strategic outcomes.

ODPC gives the organization the catalog structure needed to manage data products consistently.

ODPG gives the organization the graph structure needed to understand how those products connect to value.

One organizes the portfolio. The other explains the portfolio.

Together, they help organizations move from data product inventory to data product intelligence.

My question to the data product community:

Which relationships or graph objects do you think are still missing from this model?