What Is a Data Space, and How Does Catena-X Fit Digital Product Passport Architecture?

A data space is a governed way for organisations to discover and exchange selected data across company boundaries. Catena-X is a concrete automotive implementation of that idea, but neither Catena-X nor the wider data-space stack is a universal requirement for an EU Digital Product Passport.

Start with the jobs, not the acronyms

Most confusion comes from asking one component to do the job of another. A product-data architecture can contain several layers without turning them into one system.

This is why the question which system should own each product fact still matters when a data space is added. Representation and exchange layers can publish or move governed information without becoming authoritative for every fact.

The same separation applies to the EU DPP Registry. The Registry is a legal registration and validation layer. It is not the place where every complete DPP must be hosted and it is not a sector data space.

What a data space actually is

A useful plain-English definition is: a data space is a governed environment in which independent organisations can share selected data under agreed technical, organisational, legal and business rules.

That definition is broader than a connector or an API. The Data Spaces Support Centre separates the problem into business, governance, legal and technical building blocks. IDSA makes the same basic point from a different angle: the point is controlled data sharing between participants, not one central database.

That distinction matters because a real cross-company exchange has several questions to answer at once:

• Business: why would one participant share the data and another consume it?
• Governance: who may join, who sets rules and how disputes or policy breaches are handled?
• Legal: what agreement or permission governs the exchange?
• Semantic: do the parties mean the same thing by the data they exchange?
• Technical: how are datasets discovered, contracted for and transferred?
• Operational: how are identities, versions, logs and failures managed over time?

The emerging ISO terminology should not be overstated. As at 6 September 2026, ISO/IEC 20151-1 on dataspaces was still at Final Draft International Standard stage. That makes the standards landscape real but still moving. It is safer to describe the job the architecture performs than to imply that one final universal data-space model has already settled.

IDSA, DSSC, Dataspace Protocol, EDC and Gaia-X are not synonyms

Several names appear together in data-space presentations, but they sit at different layers.

The Dataspace Protocol does not define the complete data space. EDC does not define the complete data space either. Gaia-X is not another name for Catena-X. Each can contribute to a wider architecture without owning the whole problem.

This also explains why discovery is not permission. Finding a dataset, service or digital twin is one step. Being allowed to receive or act on it is another.

How Catena-X composes the stack for DPP exchange

Catena-X is useful because it turns abstract data-space language into a visible sequence of jobs.

A simplified DPP-related flow looks like this:

1. A participant joins the ecosystem. Identity, onboarding and ecosystem rules establish who is taking part.
2. A connector exposes discoverable assets and policies. Catena-X uses EDC-based connectivity directly or through managed services.
3. Catalogue and contract processes establish the exchange. The parties discover an offer, negotiate the relevant agreement and prepare the transfer process.
4. A Digital Twin Registry helps locate the relevant digital twin and aspects. The DTR is an ecosystem discovery component, not the EU DPP Registry.
5. The twin exposes structured information. Catena-X uses AAS-aligned digital twins and semantic aspect or submodel structures.
6. Selected DPP-related information is exchanged under the agreed conditions. Catena-X's DPP use case is deliberately concerned with controlled business-to-business information rather than pretending every DPP resource is public.

The result is not one giant Catena-X database. The architecture is deliberately distributed. Product facts can still come from existing source systems, while the data-space layers control how selected representations are discovered and exchanged.

If you need the representation side rather than the exchange side, see Digital Product Passport vs Digital Twin vs Asset Administration Shell.

EU law does not require the Catena-X stack

This boundary is important enough to state plainly.

Regulation (EU) 2024/1781 requires DPP data to use open standards and interoperable formats and requires technical, semantic and organisational end-to-end interoperability. Six DPP standards were cited as harmonised standards in July 2026. Those requirements create interoperability outcomes. They do not prescribe Catena-X, AAS, Gaia-X or EDC as the universal implementation.

The difference is practical as well as legal. A business can meet a public DPP publishing need with a much simpler architecture than a multinational supply network exchanging restricted engineering, lifecycle or traceability data between independent parties.

The EU DPP Registry implementation is therefore a separate workstream from joining a sector data space. Registering a passport does not onboard an organisation into Catena-X. Joining Catena-X does not replace the EU registration obligations that apply to an in-scope DPP.

EU Registry, resolver, Digital Twin Registry and connector do four different jobs

These components are easy to collapse into one vague idea of "discovery". They should stay separate.

A GS1 Digital Link URI and resolver can be an elegant identity and web-routing layer. It is still solving a different problem from a sector Digital Twin Registry or a data-space connector.

What data sovereignty means, and what it does not prove

Data-space programmes often use the term data sovereignty. The useful meaning is that a participant retains meaningful agency over how its data is offered and under which agreed conditions it is shared. Identity, contracts, policy expressions, connector controls and governance rules can all strengthen that position.

That is valuable, but it should not be described as an absolute technical guarantee. Once information has been disclosed to another party, contracts and technical controls can limit or deter misuse, but they do not make copying or misuse physically impossible in every architecture.

So a sound claim is: data-space mechanisms can improve controlled sharing and policy enforcement.

A claim we would not make is: a data space guarantees the recipient can never misuse the data.

Where EPCIS and source systems still fit

A richer exchange architecture does not make event standards or master systems disappear.

EPCIS remains the event and visibility layer when the business question is what happened to an identified object, where, when and in what business context. Those events can be referenced or exchanged through a wider data-space architecture without turning EPCIS into the DPP itself.

The same applies to master data. A connector can exchange a product composition, certificate status or part identifier, but the connector does not become authoritative merely because it moved the value. Provenance should continue to point back to the governed source and evidence.

When a data space is justified

A data space becomes easier to justify when several of these conditions are true:

• many independent organisations need to exchange data repeatedly;
• much of the information is restricted rather than public;
• participants need common onboarding and trust rules;
• bilateral API agreements are becoming hard to govern;
• the same datasets or services need to be discoverable by many authorised partners;
• contract and policy conditions need to travel with the exchange process;
• digital twins, component hierarchies or lifecycle information already matter operationally;
• the sector has adopted a concrete ecosystem that trading partners actually use.

In that situation, the cost of the richer architecture is solving a real coordination problem.

When a normal web DPP may be enough

Do not treat architectural complexity as a maturity score.

A simpler DPP can be the better design when the main job is to publish stable or slowly changing information to broad audiences. A persistent identifier, durable domain, web resource, governed product record and appropriate access controls may solve the requirement without a sector connector, DTR or full digital-twin stack.

CIRPASS-2 work has explicitly explored a "simplest possible" DPP architecture. That is useful counterevidence to the idea that every compliant passport must be built as an industrial data-space deployment.

The practical test is simple: what cross-company problem would the extra layer solve? If the answer is unclear, adding it because the terminology sounds advanced is likely to create more governance than value.

What is settled now and what is still moving

NOW: ESPR's interoperability requirements are law. Six DPP standards were cited as harmonised standards in July 2026. Catena-X, the Dataspace Protocol, EDC, Gaia-X and AAS all have current specifications or implementations that can be used today.

EMERGING: formal international data-space terminology is still settling. ISO/IEC 20151-1 remained at FDIS stage on 6 September 2026. Semantic convergence across different modelling approaches is also still developing.

NOT ESTABLISHED: public evidence is much stronger for specifications, products and pilots than for independent, market-wide proof of ROI or adoption for DPP data-space architectures. Vendor and ecosystem examples demonstrate capability. They should not be turned into universal economic claims.

Practical questions before choosing a data space

Before adding Catena-X or another data-space architecture, answer these questions in order:

1. Which product facts remain authoritative in existing systems?
2. Which information is public and which genuinely needs controlled B2B exchange?
3. Who are the participants and what shared governance do they need?
4. What has to be discovered: a web resource, a digital twin, a dataset or an executable service?
5. What contract, policy or entitlement must be checked before data moves?
6. Which semantic model must the parties share?
7. Do trading partners already use the chosen ecosystem and versions?
8. What happens if the connector, service provider or ecosystem changes?
9. Which obligations still sit outside the data space, including EU DPP registration?

If those questions point to repeated governed exchange across organisations, a data space can be a sensible architecture. If they point mainly to durable publication of passport information, start simpler.

What would change this page

This answer would need material review if:

• ISO/IEC 20151-1 moves from FDIS to a final published standard with materially different concepts;
• Catena-X materially changes its DPP, Digital Twin Registry or connector architecture;
• the Dataspace Protocol or EDC changes in a way that alters the role boundaries described here;
• EU DPP rules begin to prescribe an industrial data-space technology that the current framework does not require;
• independent evidence establishes materially different adoption or economic outcomes at scale.

Sources

• Regulation (EU) 2024/1781, ESPR
  EU law
• Commission Implementing Decision (EU) 2026/1736 on harmonised DPP standards
  Delegated act
• Commission Implementing Regulation (EU) 2026/1778 on the DPP Registry
  Delegated act
• Data Spaces Support Centre Blueprint v3.0
• IDSA: What Is a Dataspace?
• ISO/IEC 20151-1 status page
• Dataspace Protocol 2025-1
• Eclipse Dataspace Components Developer Handbook
• Gaia-X Trust Framework Architecture
• Catena-X CX-0002 Digital Twins in Catena-X
• Catena-X CX-0143 Digital Product Passport use case standard
• GS1 Digital Link URI Syntax 1.7.0
  Standards body
• GS1-Conformant Resolver Standard
  Standards body
• GS1 EPCIS and CBV Standard
• CIRPASS-2 / TNO: The simplest possible Digital Product Passport system