Modern businesses rarely lack data.

They lack a reliable way to exchange it across organisational boundaries.

A manufacturer may hold product-design information in PLM, order and supplier data in ERP, production records in MES, environmental calculations in LCA software and service history in another platform.

Its suppliers, logistics providers, auditors, regulators, repairers and recyclers maintain their own systems, definitions and access rules.

Digital Product Passports create a structured way to connect important information to a product.

Data spaces provide the trusted environment in which different organisations can discover, request and exchange that information without surrendering all control to one central platform.

Interoperability determines whether the participating systems can technically connect, understand the same data, apply compatible rules and collaborate operationally.

These concepts solve different parts of the same problem:

• The Digital Product Passport describes the product.
• The data space connects the organisations and services exchanging information.
• Interoperability allows the exchanged information to remain meaningful and usable.
• Governance determines who may participate and how data may be used.

The future of trusted business data exchange will not be one universal database owned by one technology provider.

It will be a network of governed systems that can exchange verified information through shared identities, standards, semantics, policies and interfaces.

---

Quick answer: How do data spaces and Digital Product Passports work together?

A Digital Product Passport is a structured digital record associated with a product, model, batch, item, component or material.

A data space is a governed environment in which independent organisations can exchange data under agreed technical, contractual and usage rules while retaining control over their own systems and information.

They work together as follows:

1. Manufacturers and supply-chain partners create product and lifecycle data.
2. The information is standardised, validated and connected to a persistent product identity.
3. Relevant information is assembled into a Digital Product Passport.
4. A data-space connector exposes authorised data or services to approved participants.
5. Identity, trust and policy services verify the participants and permitted purpose.
6. Common data models and semantics ensure that receiving systems interpret the information correctly.
7. Customers, partners, repairers, recyclers, auditors and authorities receive only the information they are entitled to use.

The core distinction is:

A DPP organises trusted data around a product. A data space governs how that data moves between organisations.

Key takeaways

1. A data space is not necessarily a central database or shared cloud account.
2. Participants can retain their own systems while exchanging selected data through common rules, services and interfaces.
3. A DPP and a data space are complementary but independent. A DPP can exist without a formal data space, and a data space can support many use cases beyond DPPs.
4. The EU Ecodesign for Sustainable Products Regulation requires DPPs to be interoperable across technical, semantic and organisational dimensions. [1]
5. Technical connectivity alone is insufficient. Participants must also agree on meaning, identity, access, responsibilities and legal usage.
6. Data sovereignty does not mean that data never leaves its source. It means that the data holder retains meaningful control over access and permitted use.
7. A data-space connector is not automatically the authoritative source of product information. It mediates controlled exchange with existing source systems and services.
8. Shared standards reduce integration friction, but standards must be implemented through mappings, validation, governance and version management.
9. Digital identities and verifiable credentials can help prove which organisations, services and representatives are participating.
10. Data contracts should define what is shared, for which purpose, under which conditions and for how long.
11. The strongest architecture keeps operational and commercially sensitive data distributed while exposing governed, purpose-specific data products.
12. Catena-X provides a practical industrial example of using a sovereign data space to support Digital Product Passports and other automotive use cases. [8]

What is a data space?

A data space is a governed digital ecosystem in which participants can share and use data under agreed rules without requiring all data to be moved into one central repository.

A data space normally combines:

• Participants
• Governance
• Identity and trust
• Data products
• Usage policies
• Data contracts
• Catalogues
• Connectors
• Common standards
• Semantic models
• Security
• Auditability
• Business and operating models

The European Commission describes Common European Data Spaces as environments where data can be exchanged securely and reliably while businesses, public bodies and individuals retain control over the data they generate. [2]

What a data space is not

A data space is not automatically:

• A data warehouse
• A data lake
• A blockchain
• One shared database
• One vendor platform
• An API marketplace
• A public open-data portal
• A cloud-storage folder
• A Digital Product Passport

It may use some of those technologies, but its defining feature is the combination of governed data exchange and participant control.

A simplified data-space transaction

A supplier may publish a data offer stating:

Data:
Verified recycled-content information

Scope:
Component family C-204

Permitted users:
Approved manufacturers

Permitted purpose:
Product carbon-footprint calculation
and Digital Product Passport creation

Retention:
24 months

Redistribution:
Not permitted

Verification:
Signed by the supplier and linked
to recognised certification evidence

The manufacturer discovers the offer, authenticates, demonstrates its entitlement, accepts the usage conditions and retrieves the authorised information through a secure interface.

The data does not become unrestricted simply because it has been shared.

What is a Digital Product Passport?

A Digital Product Passport is a structured digital record linked to a product through a unique identifier and an accessible data carrier, such as a QR code or another recognised mechanism.

Depending on the applicable product rules, the DPP may contain or provide controlled access to information such as:

• Product identity
• Manufacturer
• Responsible economic operator
• Materials and components
• Recycled content
• Environmental performance
• Substances of concern
• Certifications
• Durability
• Repair information
• Maintenance history
• Disassembly instructions
• Reuse information
• Recycling guidance
• End-of-life treatment

The exact information, granularity and access rights will depend on product-specific legislation and delegated rules.

The DPP is an access layer, not necessarily one physical record

A mature DPP can assemble information from:

• ERP
• PLM
• PIM
• MES
• Supplier systems
• LCA platforms
• Quality systems
• Certification systems
• Service platforms
• Lifecycle-event records

The information may remain distributed.

The DPP creates the governed product-centred representation through which appropriate information can be found and accessed.

How are data spaces different from Digital Product Passports?

Question	Digital Product Passport	Data space
Primary focus	A product, component, material, batch or item	An ecosystem of organisations and data services
Main purpose	Organise and expose product information	Govern trusted cross-organisational exchange
Core object	Product record	Data product, service or transaction
Typical users	Customers, operators, repairers, recyclers, regulators	Businesses, authorities, service providers and platforms
Identity requirement	Product and responsible-actor identity	Participant, service and representative identity
Governance	Product-data ownership and access	Ecosystem-wide participation and usage rules
Data location	May be distributed across several systems	Normally federated across participant-controlled systems
Interoperability need	Passport formats, semantics and lifecycle	Identity, services, contracts, protocols and semantics
Can exist independently?	Yes	Yes
Strongest combined value	Trusted lifecycle data exchanged across the ecosystem	Trusted infrastructure for discovering and consuming DPP data

A DPP becomes more useful when it can obtain and exchange data across a trusted ecosystem.

A data space becomes more valuable when it supports a concrete business use case, such as product carbon-footprint exchange, supplier quality, traceability or DPP generation.

Why interoperability is the decisive requirement

Two systems can exchange a JSON file and still fail to interoperate.

They may disagree about:

• What each field means
• Which unit is being used
• Which product the data describes
• Whether the information applies to a model, batch or item
• Which methodology produced a result
• Whether the issuer is recognised
• Who is permitted to reuse the data
• Whether a newer version exists
• Which organisation is responsible for an error

Interoperability must therefore be considered at several levels.

---

1. Technical interoperability

Technical interoperability answers:

Can the systems connect and exchange data?

It includes:

• APIs
• Protocols
• Authentication
• Encryption
• Data-transfer formats
• Event interfaces
• Connectors
• Service discovery
• Error handling
• Availability
• Version negotiation

Technical interoperability may use:

• REST
• GraphQL
• Event streaming
• Message queues
• File exchange
• OPC UA
• EPCIS
• EDI
• Webhooks
• Data-space connectors

Technical compatibility is necessary, but it does not establish common meaning.

2. Syntactic interoperability

Syntactic interoperability answers:

Is the data structured in a format the receiving system can parse?

Examples include:

• JSON
• JSON-LD
• XML
• CSV
• RDF
• Protobuf
• Defined API schemas
• Event schemas

Two organisations may agree that a product event uses:

{
  "productId": "P-1092",
  "eventType": "SHIPPED",
  "eventTime": "2026-06-20T12:30:00Z"
}

The receiving system can parse the structure.

It still needs to understand what P-1092, SHIPPED and the timestamp represent.

3. Semantic interoperability

Semantic interoperability answers:

Do the systems interpret the data in the same way?

It depends on:

• Common data models
• Vocabularies
• Ontologies
• Code lists
• Unit definitions
• Identifier schemes
• Methodology references
• Granularity rules
• Version definitions

Consider:

recycled_content = 40

This value is unusable unless participants agree on questions such as:

• Forty percent of what?
• By mass, volume or value?
• Pre-consumer or post-consumer?
• Product, component or packaging?
• Measured or estimated?
• Verified by whom?
• Applicable to which production period?

The proposed 2026 implementation arrangements for the EU DPP Registry illustrate the importance of this layer: the draft describes a machine-readable semantic repository containing common data models, definitions, vocabularies and versioning information for DPP data. As of June 2026, those implementation arrangements remain a Commission draft rather than a final implementing regulation. [4]

4. Organisational interoperability

Organisational interoperability answers:

Can participating organisations operate the process consistently?

It includes agreement on:

• Roles
• Responsibilities
• Data ownership
• Approval
• Service levels
• Incident response
• Data correction
• Escalation
• Participant onboarding
• Participant removal
• Support
• Cost allocation

For example, participants must agree:

• Who corrects an inaccurate supplier claim?
• Who informs downstream users?
• Who can mark data as superseded?
• Who resolves conflicting values?
• Who maintains mappings when a standard changes?

5. Legal and contractual interoperability

Legal interoperability answers:

Can the information be shared and used lawfully across participants and jurisdictions?

Relevant areas may include:

• Data protection
• Intellectual property
• Trade secrets
• Competition law
• Product regulation
• Liability
• Retention
• International transfers
• Contractual restrictions
• Data Act obligations
• Sector-specific law

A technically functioning data exchange may still be unusable if the receiving organisation lacks a legal basis or contractual permission.

6. Trust and governance interoperability

Trust interoperability answers:

Can each participant verify who the others are, what they are authorised to do and which rules they follow?

It may involve:

• Organisational identity
• Representative authority
• Verifiable credentials
• Trust registries
• Certification
• Participant policies
• Compliance rules
• Audit records
• Dispute procedures

The Gaia-X Trust Framework, for example, aims to provide common governance and baseline interoperability through machine-readable information, verifiable statements and computable compliance rules. [7]

What does the EU require for DPP interoperability?

The Ecodesign for Sustainable Products Regulation states that Digital Product Passports must be fully interoperable across the technical, semantic and organisational aspects of end-to-end communication and data transfer.

It also requires:

• Data authentication, reliability and integrity
• Role-based rights to introduce, modify or update data
• Security and privacy
• Continued availability
• Links between replacement and previous passports
• Access based on the rights of different stakeholders
• Avoidance of vendor lock-in through interoperable exchange [1]

The implication is significant.

A DPP system should not be designed only as a visually attractive product page.

It needs an interoperable data and service architecture behind it.

The EU DPP Registry and decentralised architecture

Under the ESPR, the European Commission must establish a DPP Registry by 19 July 2026.

The regulation requires it to store at least unique identifiers and provide registration identifiers that can support enforcement and customs processes. [3]

The registry does not necessarily become the central storage location for every detailed product-data record.

Detailed passports may remain hosted by the responsible economic operator or an authorised service provider, while the registry supports identification, registration and regulatory discovery.

In May 2026, the Commission published draft implementation arrangements proposing components such as:

• A secure user interface
• A registration API
• User verification
• Identification and authorisation
• Registration identifiers
• A semantic repository
• Operational logging
• References to DPP service providers
• Automatic validation of submitted registration data [4]

Because these arrangements were still in draft form as of June 2026, organisations should avoid treating every proposed detail as final.

The strategic direction is nevertheless clear:

DPP infrastructure is being designed as a distributed and interoperable system rather than one universal product database.

What is data sovereignty?

Data sovereignty is the ability of a data holder to retain meaningful control over how data is accessed, processed and reused.

It does not necessarily mean:

• Data never leaves the company
• Data must remain on one server
• No cloud provider may be used
• Every transaction requires a human
• Data cannot be copied

It means that exchange occurs under enforceable conditions.

Those conditions may specify:

• Permitted participant
• Permitted purpose
• Permitted dataset
• Duration
• Geographic restrictions
• Redistribution rules
• Retention
• Deletion
• Processing conditions
• Audit requirements

The International Data Spaces Reference Architecture places self-determination and control over data usage with the parties that collect and provide the data rather than automatically transferring control to a central platform. [6]

Access control versus usage control

Access control determines whether a participant can obtain data.

Usage control determines what may happen after access.

Example:

Access:
Supplier A may retrieve this dataset.

Usage:
The dataset may be used only for:
- product carbon-footprint calculation,
- regulatory reporting,
- generation of the relevant DPP.

It may not be:
- resold,
- used to compare supplier pricing,
- shared with unrelated parties.

Technical enforcement after data has been downloaded is difficult.

A realistic usage-control model combines:

• Technical restrictions
• Contractual obligations
• Audit
• Monitoring
• Trusted execution where appropriate
• Sanctions
• Organisational governance

The role of identity and verifiable credentials

Trusted exchange requires participants to answer:

• Who is requesting the data?
• Which organisation do they represent?
• Is that organisation an approved participant?
• Is the representative authorised?
• Which certification or role do they hold?
• Is that status still valid?

Traditional bilateral onboarding repeats these checks for every relationship.

A data space can standardise part of the process through:

• Participant identities
• Organisational credentials
• Service credentials
• Trust anchors
• Certification registries
• Delegated authority
• Machine-readable policies

A manufacturer might present credentials proving:

• Legal registration
• Data-space membership
• Industry role
• Security certification
• Authority to request a dataset
• Acceptance of ecosystem rules

Verification still requires governance.

A cryptographically valid credential is not useful unless the verifier recognises the issuer and understands what the credential means.

Product identity is the backbone

Data cannot be exchanged reliably when participants cannot identify the same product.

A robust identity model may need to distinguish:

• Product model
• Product variant
• Batch
• Lot
• Serialised item
• Component
• Material
• Facility
• Organisation
• Shipment
• Lifecycle event

Why granularity matters

Suppose a supplier reports:

Carbon footprint: 18 kg CO₂e

Does this apply to:

• Every unit of the model?
• One manufacturing batch?
• One specific item?
• One component?
• One facility and production period?

The DPP must link every claim to the correct granularity.

Identity resolution

A DPP ecosystem may require services that:

1. Resolve a product identifier.
2. Discover which digital record or asset represents it.
3. Identify authorised data endpoints.
4. Retrieve the permitted data representation.
5. Verify provenance, version and status.

Discovery should not require every organisation to know the internal URLs of every supplier.

Common data models and semantic assets

A shared model does not mean every participant must replace its internal data structures.

Instead, each organisation maps its source systems to a common exchange model.

Supplier system
    ↓ mapping
Common component model
    ↓ exchange
Manufacturer mapping
    ↓
Manufacturer PLM or DPP platform

Components of a semantic layer

• Entity definitions
• Attribute definitions
• Relationships
• Units
• Code lists
• Vocabularies
• Ontologies
• Validation rules
• Methodology references
• Version history
• Multilingual labels

Canonical model versus universal model

A common exchange model should be sufficiently precise to support interoperability.

It should not attempt to contain every internal field used by every participant.

A practical model identifies the information required for the shared use case while allowing controlled extensions.

GS1 EPCIS and traceability events

Product information is not only static attributes.

Lifecycle exchange also requires events:

• Produced
• Packed
• Shipped
• Received
• Installed
• Inspected
• Repaired
• Transferred
• Refurbished
• Recycled

GS1 EPCIS is a standard for sharing supply-chain visibility events through a common language across and within enterprises.

EPCIS 2.0 adds support for features including JSON and JSON-LD representations, sensor information and certification details. [9]

An event can answer dimensions such as:

• What object was involved?
• When did the event happen?
• Where did it happen?
• Why did it happen?
• What business context applied?

EPCIS does not by itself create a complete DPP or data-space governance system.

It can form part of the interoperable traceability layer.

How product data moves across a trusted ecosystem

Step 1: Source systems create the data

Examples include:

• Supplier master data
• Material declarations
• Bill of materials
• Product specifications
• Manufacturing records
• Test results
• Carbon calculations
• Certifications
• Service events
• End-of-life information

Step 2: Connectors ingest or expose information

Connections may use:

• APIs
• Events
• Files
• ERP connectors
• Supplier portals
• Industrial protocols
• Data-space connectors

The integration layer should retain source and timestamp information.

Step 3: Data is mapped to common models

Transformation may include:

• Field mapping
• Unit conversion
• Identifier resolution
• Vocabulary mapping
• Schema validation
• Language normalisation
• Methodology alignment

Step 4: Data is verified and governed

Checks may determine:

• Is the source recognised?
• Is the schema valid?
• Is the data complete?
• Is the value within an acceptable range?
• Is supporting evidence available?
• Does the submitter have authority?
• Has the information expired?
• Is human approval required?

Step 5: A connected product record is assembled

The product record links:

• Product identity
• Components
• Materials
• Suppliers
• Facilities
• Evidence
• Certifications
• Lifecycle events

Step 6: DPP views are generated

Different views may be produced for:

• Customers
• Business partners
• Repairers
• Recyclers
• Regulators
• Customs
• Internal users

Step 7: Data products are published to the data space

A data offer may describe:

• Dataset
• API
• Event stream
• Credential
• Analytical service
• Product-passport view

Step 8: The receiving participant is verified

The system evaluates:

• Participant identity
• Membership
• Role
• Credential status
• User authority
• Purpose
• Contract
• Policy

Step 9: The data is exchanged

The exchange is:

• Authenticated
• Encrypted
• Logged
• Policy-bound
• Versioned
• Purpose-specific

Step 10: Lifecycle updates continue

New information may be added through:

• Maintenance
• Repair
• Transfer
• Reuse
• Refurbishment
• Recycling

The DPP therefore becomes a lifecycle information service rather than a one-time publication.

Data products: The practical unit of exchange

A data space should not expose databases indiscriminately.

It should expose governed data products.

A data product may include:

• Defined dataset
• Owner
• Purpose
• Schema
• Access method
• Quality level
• Service level
• Usage policy
• Version
• Support contact
• Pricing or commercial conditions

Example:

Data product:
Battery component composition

Owner:
Component Supplier Ltd.

Scope:
Component family B-18

Format:
Versioned JSON-LD API

Quality:
Supplier verified,
certificate references included

Use:
Battery DPP and recycling assessment

Update frequency:
Per production batch

Retention:
Five years

Access:
Approved manufacturers and recyclers

Treating data as a product makes accountability clearer than simply publishing an endpoint.

Data contracts

A data contract records the agreement between producer and consumer.

It can define:

• Schema
• Semantic meaning
• Quality rules
• Availability
• Update frequency
• Allowed use
• Retention
• Liability
• Change notification
• Deprecation
• Audit
• Commercial terms

Why data contracts matter

An API may remain technically operational while silently changing:

• Unit
• Enumeration
• Calculation method
• Granularity
• Meaning
• Quality threshold

A data contract turns these assumptions into managed commitments.

Data quality and trust are different

A trusted participant can provide poor data.

A well-formatted dataset can still be incorrect.

Data quality should assess:

• Accuracy
• Completeness
• Consistency
• Timeliness
• Validity
• Granularity
• Provenance
• Verification
• Methodology
• Representativeness

Trust should assess:

• Who produced the data?
• Is the producer recognised?
• Did the producer have authority?
• Was the record altered?
• Is the credential valid?
• Which assurance process applies?

Both are necessary.

Does a data space require blockchain?

No.

A data space can be implemented through:

• Federated identity
• Secure APIs
• Digital signatures
• Trust registries
• Policy services
• Contracts
• Audit logs
• Connectors

A distributed ledger may be considered when:

• Multiple independent organisations need shared state
• No one operator should control the history
• Multi-party approval is required
• Tamper-evident shared events create measurable value
• Governance can support a distributed network

Blockchain does not automatically solve:

• Data quality
• Semantic interoperability
• Participant trust
• Legal permission
• Source-system integration
• Governance

The technology should follow the trust problem.

Catena-X as a practical industrial example

Catena-X is an automotive data ecosystem that supports use cases including:

• Digital Product Passports
• Product carbon footprint
• Quality management
• Traceability
• Circular economy
• Business-partner data

Its DPP approach describes an open, standardised and vendor-independent foundation for exchanging product data across manufacturers, suppliers and service providers in a sovereign data space. [8]

Catena-X also uses discovery and digital-twin concepts to locate relevant asset information across the ecosystem.

The lesson is not that every industry should duplicate Catena-X exactly.

It demonstrates several reusable principles:

• Start with business use cases.
• Define shared semantic models.
• Establish participant identity and governance.
• Use interoperable components.
• Avoid one proprietary central platform.
• Build discovery and data-exchange services.
• Certify implementations and participants where necessary.

Cross-data-space interoperability

The long-term goal is not one data space for every activity.

Organisations may participate in separate spaces for:

• Automotive
• Manufacturing
• Energy
• Mobility
• Health
• Agriculture
• Finance
• Construction
• Tourism
• Public administration

A product may move through several of them.

For example:

Automotive data space
    ↓ material or component information
Manufacturing data space
    ↓ production and quality data
Energy data space
    ↓ charging and usage information
Circularity data space
    ↓ recovery and recycling information

Cross-data-space interoperability requires alignment across:

• Participant identity
• Trust frameworks
• Data models
• Policy languages
• Catalogues
• Connector protocols
• Credentials
• Contract models
• Audit evidence
• Dispute processes

The DSSC defines cross-data-space interoperability as the ability for participants to exchange or access data across more than one data space through compatible governance, business and technical frameworks. [5]

Where does the business value come from?

1. Secure supplier collaboration

Suppliers can share selected:

• Composition data
• Certifications
• Carbon information
• Quality evidence
• Provenance
• Capacity information

without exposing unrelated internal systems.

2. Regulatory readiness

A governed information layer can help organisations:

• Locate required data
• Identify gaps
• Validate evidence
• Produce DPPs
• Respond to authorities
• Update records when rules change

3. Product transparency

Customers and partners can receive clearer information about:

• Product identity
• Materials
• Origin
• Sustainability
• Repair
• Certifications
• End-of-life options

4. Circularity and recycling

Repairers and recyclers can access information needed to:

• Diagnose
• Disassemble
• Replace components
• Assess reuse
• Identify materials
• Manage hazardous substances
• Select recovery routes

5. Service and maintenance

A service provider can retrieve:

• Correct product version
• Service history
• Compatible parts
• Maintenance instructions
• Software version
• Safety information

6. Cross-company analytics

Participants can contribute approved data to:

• Demand forecasting
• Risk analysis
• Carbon calculation
• Supply-chain resilience
• Quality benchmarking
• Circularity measurement

Privacy-preserving analysis or compute-to-data approaches may be appropriate where raw data should not be broadly transferred.

7. Recall and risk response

Connected product and lifecycle data can help identify:

• Affected batches
• Shared components
• Supplier relationships
• Distribution routes
• Service events
• Downstream owners or operators where legally permitted

8. Reduced bilateral integration

Without shared rules, every new relationship requires:

• Custom mapping
• Custom authentication
• Contract negotiation
• Manual onboarding
• Custom API development

Data-space standards can make more of that process reusable.

A reference architecture

A production architecture may contain the following layers.

1. Enterprise source systems

• ERP
• PLM
• PIM
• MES
• LCA
• Quality management
• Supplier systems
• Service systems
• Document repositories

2. Integration and connector layer

• APIs
• File import
• Event streams
• Industrial connectors
• Data-space connectors
• Validation
• Transformation

3. Identity and resolution

• Product identifiers
• Organisation identifiers
• Facility identifiers
• Credential resolution
• Participant identity
• Asset discovery

4. Semantic and data layer

• Common data models
• Vocabularies
• Ontologies
• Unit definitions
• Validation schemas
• Mapping
• Versioning

5. Trust layer

• Participant verification
• Verifiable credentials
• Trust anchors
• Certification
• Status
• Delegated authority

6. Policy and governance layer

• Access control
• Usage policy
• Consent where applicable
• Data contracts
• Retention
• Audit
• Compliance

7. DPP core

• Product records
• Component relationships
• Passport templates
• Evidence
• Lifecycle events
• Access views
• Reporting

8. Data-space services

• Catalogue
• Discovery
• Contract negotiation
• Exchange
• Routing
• Monitoring
• Policy enforcement

9. Experience and consumption

• Customer passport
• Partner API
• Supplier portal
• Repair interface
• Recycler view
• Regulator service
• Analytics platform
• AI agents

A practical implementation roadmap

Phase 1: Select a real exchange problem

Examples:

• Collect supplier carbon data
• Verify component certificates
• Exchange repair information
• Support recycling
• Generate a battery passport
• Track quality events

Do not begin by trying to build a universal data space.

Phase 2: Map the ecosystem

Identify:

• Producers
• Consumers
• Data owners
• Authorities
• Service providers
• Trust providers
• Governance body
• Dispute authority

Phase 3: Define the data product

Document:

• Business purpose
• Dataset
• Source
• Granularity
• Schema
• Quality
• Method
• Access
• Usage
• Lifecycle

Phase 4: Establish product and participant identity

Define how the ecosystem identifies:

• Organisation
• Representative
• Product
• Batch
• Item
• Component
• Facility
• Event

Phase 5: Create the common semantic model

Start only with the attributes required for the use case.

Define:

• Meaning
• Type
• Unit
• Cardinality
• Method
• Source
• Version
• Extension mechanism

Phase 6: Define governance

Agree on:

• Admission
• Roles
• Responsibilities
• Data correction
• Certification
• Liability
• Support
• Costs
• Removal
• Dispute resolution

Phase 7: Design access and usage policies

For each exchange, specify:

• Who
• What
• Why
• How long
• Where
• Which onward uses
• Which audit evidence

Phase 8: Integrate source systems

Avoid a new manual compliance database where possible.

Connect to authoritative operational sources.

Phase 9: Implement identity and trust

Add:

• Organisational verification
• Credentials
• Role validation
• Trust registry
• Revocation or status
• Representative authority

Phase 10: Pilot exchange between independent organisations

A pilot controlled entirely by one company does not prove ecosystem interoperability.

Include at least:

• One data producer
• One consumer
• Independent infrastructure
• Real access rules
• Real data mappings
• Error and dispute scenarios

Phase 11: Test interoperability

Test:

• Schema compatibility
• Semantic meaning
• Identity
• Discovery
• Access
• Policy
• Revocation
• Versioning
• Availability
• Audit
• Cross-border or cross-organisation operation

Phase 12: Measure business outcomes

Measure:

• Onboarding time
• Data-collection effort
• Mapping effort
• Verification time
• Manual reconciliation
• Data defects
• Compliance preparation
• Integration cost
• Partner participation
• Lifecycle use

Phase 13: Scale through reusable building blocks

Create reusable:

• Connectors
• Identity services
• Policy templates
• Semantic mappings
• Product templates
• Data contracts
• Partner onboarding
• Test suites

Common mistakes

1. Treating the data space as a central data lake

This can undermine sovereignty and create one attractive breach target.

2. Starting with infrastructure rather than a use case

A connector network without valuable data products will not create participation.

3. Assuming APIs equal interoperability

APIs provide access. They do not guarantee common meaning or compatible governance.

4. Creating one giant universal data model

The model becomes too complex to implement and too generic to be useful.

5. Ignoring data quality

A secure exchange of inaccurate information is still a failure.

6. Treating governance as documentation

Policies must be reflected in:

• Identity
• Permissions
• Contracts
• Operations
• Monitoring
• Enforcement

7. Exposing too much data

Data spaces should support purpose limitation and selective exchange—not universal access.

8. Depending on one vendor-specific format

A proprietary implementation can recreate the lock-in that the ecosystem was intended to avoid.

9. Ignoring smaller suppliers

SMEs may need:

• Portals
• File uploads
• Mapping support
• Shared services
• Managed connectors
• Clear onboarding

10. Assuming blockchain creates trust

Trust also requires identity, quality, governance, liability and assurance.

How should success be measured?

Interoperability metrics

• Successful cross-system exchanges
• Schema-validation success
• Semantic mapping errors
• Supported standards
• Version compatibility
• Cross-data-space transactions

Data-quality metrics

• Completeness
• Verification rate
• Stale-data rate
• Rejected submissions
• Conflicting values
• Provenance coverage

Ecosystem metrics

• Active participants
• Supplier participation
• Time to onboard
• Published data products
• Data-product consumption
• Partner satisfaction

Operational metrics

• Exchange latency
• Availability
• Contract-negotiation time
• Connector failures
• Support incidents
• Cost per exchange

Business metrics

• Compliance effort
• Recall response time
• Supplier-verification time
• Service efficiency
• Repair success
• Reuse or recycling activity
• New data-enabled revenue
• Reduced bilateral integration cost

What should organisations do now?

Businesses can prepare before every regulation and standard is final.

The most durable actions are:

1. Define stable product, component and participant identities.
2. Locate authoritative source systems.
3. Separate structured data from supporting documents.
4. Record data provenance and methodology.
5. Establish data ownership.
6. Improve supplier-data quality.
7. Develop canonical product-data models.
8. Expose governed APIs and events.
9. Define role- and purpose-based access.
10. Pilot one cross-company use case.
11. Avoid locking the architecture to one platform.
12. Participate in relevant industry standards and ecosystems.

The future of trusted business data exchange

The next stage of enterprise integration will move beyond transferring files between known bilateral partners.

Business data will increasingly be:

• Discoverable
• Machine-readable
• Semantically defined
• Identity-bound
• Policy-controlled
• Verifiable
• Portable
• Purpose-limited
• Auditable

Digital Product Passports will become one of the most visible interfaces to that infrastructure.

But the passport alone is not the end state.

The larger opportunity is an interoperable product-data ecosystem where:

• Suppliers provide trusted claims once
• Manufacturers reuse them across products and reporting
• Service providers update lifecycle records
• Recyclers receive actionable information
• Regulators verify evidence efficiently
• Customers receive appropriate transparency
• New services operate without recreating every integration relationship

The data remains distributed.

Trust becomes federated.

Meaning becomes shared.

Access becomes governed.

Conclusion

Data spaces, Digital Product Passports and interoperability should not be treated as competing technology concepts.

They represent three layers of the same transformation.

• The DPP organises information around the product.
• The data space governs exchange across independent organisations.
• Interoperability allows systems, participants and rules to work together.
• Trust services prove identity, authority and assurance.
• Data contracts and policies control use.
• Governance makes the ecosystem sustainable.

A business does not create trusted exchange merely by publishing an API or adding a QR code.

It must establish:

• Shared identity
• Common meaning
• Data quality
• Access policy
• Participant trust
• Lifecycle governance
• Operational responsibility
• Technical resilience

The key question is not:

Where can we centralise all product data?

It is:

How can authorised participants exchange the minimum trusted information they need while preserving meaning, control and accountability across the full product lifecycle?

That is the foundation of the next generation of business data exchange.

Frequently Asked Questions

What is a data space?

A data space is a governed ecosystem where independent organisations exchange data under shared technical, contractual and usage rules while retaining control over their own systems.

Is a data space a central database?

Not necessarily. Most data-space architectures are federated, meaning data can remain with the participant that owns or operates it.

What is a Digital Product Passport?

A DPP is a structured digital record linked to a product, component, batch, item or material through a unique identifier.

How does a DPP relate to a data space?

The DPP organises product information. The data space enables that information to be exchanged securely across organisations.

What is interoperability?

Interoperability is the ability of systems and organisations to exchange information and use it consistently across technical, semantic, organisational and governance boundaries.

What is semantic interoperability?

Semantic interoperability means that participating systems understand exchanged data in the same way.

What is data sovereignty?

Data sovereignty is the ability of a data holder to retain meaningful control over how its data is accessed, processed and reused.

Does a data space require blockchain?

No. Data spaces can use conventional identity, API, policy, signature and audit technologies.

What is a data-space connector?

A connector is a controlled interface that enables a participant to publish, request or exchange data and apply relevant identity, security and policy rules.

Does a DPP require a data space?

No. A DPP can operate without a formal data space, although data-space infrastructure can improve cross-company exchange.

Can one company own a data space?

One organisation may operate infrastructure, but a trusted multi-party data space normally requires governance that represents the wider participant ecosystem.

What is a data product?

A data product is a governed and documented dataset or service with a defined owner, purpose, interface, quality level and usage conditions.

What is a data contract?

A data contract defines the structure, semantics, quality, service commitments and permitted uses of exchanged data.

Why are unique identifiers important?

They ensure that participating systems refer to the same product, organisation, facility, batch, item or lifecycle event.

What is Catena-X?

Catena-X is an automotive data ecosystem that supports sovereign data exchange for use cases including DPPs, product carbon footprints, traceability and quality management.

What is GS1 EPCIS?

EPCIS is a GS1 standard for recording and sharing supply-chain visibility events using a common data model.

What is the biggest interoperability challenge?

The hardest challenge is often achieving common meaning and governance—not creating the technical API connection.

How should a company begin?

Start with one valuable cross-company use case, define the required data product, establish identities and governance, and then pilot exchange between independent participants.