The European Commission published its official DPP semantic data model on 30 October 2026. For companies already implementing Battery Passports using Catena-X, AAS, BatteryPass-Ready, CIRPASS-based approaches or proprietary systems, one question has become urgent: does your existing implementation actually meet the EU's new requirements?
A new EU data model, just months before the deadline
Imagine this situation.
Your company has spent months preparing for the EU Battery Passport. Your IT teams have completed their integrations. Your suppliers have provided the necessary information. Your Digital Product Passports are generated, your QR codes work, and your solution has successfully passed the tests required by your chosen technical framework.
You believe you are ready for 18 February 2027.
Then, on 30 October 2026, the European Commission publishes its official Digital Product Passport semantic data model, accompanied by new technical guidance, validation specifications and Registry integration documentation.
And the structure does not necessarily match the one your system was designed to produce.
Does this mean your Battery Passport implementation needs to be revised? Could your existing passports fail EU Registry validation? And could the requirements change again before February 2027?
These are no longer hypothetical architectural questions. They are practical compliance and implementation risks that manufacturers, importers and their technology providers need to assess now.
The good news: existing investments in collecting product data, establishing traceability and connecting suppliers are not automatically lost.
The less comfortable news: a working Battery Passport is not necessarily an EU Registry-ready Battery Passport. We covered what the Registry stores and checks in The EU Digital Product Passport Registry Is Live: What Does It Actually Validate?.
1. The industry did not wait for the Commission
Over the past several years, companies have relied on multiple credible initiatives to prepare for the Digital Product Passport.
These initiatives have helped manufacturers build data models, connect supply chains, exchange product information and develop technical solutions before the European framework was fully defined.
Among the most influential are:
Catena-X and Eclipse Tractus-X
Catena-X has established an industrial framework for exchanging product and supply-chain information, particularly within the automotive sector.
Its EcoPass ecosystem includes Digital Product Passport and Battery Passport models based on Semantic Aspect Meta Models (SAMM), with supporting components for digital twins and controlled data exchange.
Catena-X brings considerable value for collaboration between automotive manufacturers, battery producers and their suppliers.
However, compatibility with the Catena-X ecosystem and conformity with the Commission's newly published semantic model are two different things.
An implementation can work correctly within Catena-X while still requiring a transformation, additional data or validation changes for EU Registry registration.
Asset Administration Shell (AAS) and IDTA
The Industrial Digital Twin Association (IDTA), together with Catena-X and Battery Pass contributors, developed an AAS-based Digital Battery Passport approach.
In March 2026, the initiative presented seven AAS submodel specifications designed to structure Battery Passport information using established industrial standards.
These submodels provide an important foundation for interoperable industrial data exchange.
But an AAS-compliant representation does not, by itself, demonstrate that every attribute and constraint matches the Commission's current DPP semantic specifications.
Battery Pass and BatteryPass-Ready
The Battery Pass initiative, followed by BatteryPass-Ready, has played a substantial role in translating the EU Battery Regulation into practical data requirements.
Its data attribute longlists, semantic models, category-specific JSON schemas and validation environment have supported companies preparing for the February 2027 deadline.
However, BatteryPass-Ready validation is based on its own published models and test specifications.
Passing those tests is useful technical evidence. It is not automatically proof that the same passport passes the Commission's semantic validation rules. See also Battery Passport Compliance Testing with BatteryPass-Ready.
CIRPASS and CIRPASS-2
The CIRPASS initiatives have contributed to DPP architecture, semantic interoperability, ontologies and experimental implementations across several product sectors.
CIRPASS-2 published ontology documentation in October 2026, including a horizontal core and sector-specific concepts.
Importantly, the project explicitly states that its ontologies are exploratory and do not constitute the official EU DPP ontology.
They remain valuable for interoperability and research, but should not be confused with the authoritative semantic repository established by the Commission.
GS1, ERP systems and proprietary solutions
Other companies have built their implementations around GS1 identification standards, GS1 Digital Link, ERP or PLM data structures, or bespoke JSON-based applications.
These are not necessarily competing approaches.
For example, GS1 Digital Link addresses identification and access to digital resources. It does not, on its own, define every mandatory Battery Passport attribute or the Commission's complete semantic model.
Similarly, integrating product data from SAP or another ERP system does not automatically establish EU DPP semantic conformity.
The important distinction is that an industrial data standard, an identification standard, an exchange architecture and an official regulatory data model can serve different purposes.
They can coexist. But their interoperability must be implemented and tested.
2. What exactly changed on 30 October 2026?
The European Commission published the first release of its DPP semantic data artifacts, version 1.0.0, together with its Semantic Data Guide and Registry integration documentation.
The model establishes a common approach to defining, structuring and validating Digital Product Passport data.
It introduces a shared semantic foundation for future product groups, with battery-specific extensions and subgroups.
Key technical elements include:
- Common vocabularies defining the meaning of data attributes.
- SHACL shapes describing semantic validation constraints.
- Generated JSON Schema, XML Schema and JSON-LD resources.
- Standardised representations of values, units, identifiers and multilingual information.
- Product-specific data models, including battery category requirements.
- Versioned semantic artifacts and releases.
This is significant because the EU framework is designed to support Digital Product Passports across multiple industries, rather than only batteries.
The issue is not simply that field names may differ between two JSON documents.
Different models can describe similar information while imposing different technical and semantic constraints.
For example, a system may store a battery's manufacturing location as an unstructured address, while the European model expects specific structured location attributes.
A technical measurement may exist in an ERP database but lack the unit or reference conditions required by the applicable European schema.
A material name represented as free text may need to be expressed using a controlled vocabulary.
Or information accessible through one generic user role may need to be exposed through more precisely defined access categories.
Such differences can require additional data, revised mappings, new validation rules or changes to the way information is presented.
They are not necessarily reasons to rebuild the entire system.
But they cannot safely be ignored.
3. Is the new EU model mandatory?
This is where companies need to be particularly careful.
Regulation (EU) 2023/1542 establishes the legal Battery Passport obligations, including the relevant information under Annex XIII.
The Commission's semantic model does not replace that regulation.
However, Commission Implementing Regulation (EU) 2026/1778 establishes requirements for the DPP Registry and its semantic repository.
Article 11(3) requires the data contained in a Digital Product Passport to be structured in accordance with the common data models and semantic definitions published in that repository.
The distinction matters.
Using Catena-X, AAS, BatteryPass-Ready, GS1 or another recognised framework is not prohibited.
But compliance with one of those frameworks is not a substitute for demonstrating conformity with the applicable EU requirements.
A manufacturer must establish that its final DPP representation, available through the relevant interfaces, meets the European rules.
That may be achieved through a suitable conversion or interoperability layer rather than replacing the manufacturer's existing data architecture.
The right question is therefore not which industry framework is best.
It is whether the architecture can produce a compliant, complete and semantically correct EU Digital Product Passport.
4. The critical issue: the EU Registry will validate your passport
For companies already approaching deployment, this may be the most important clarification.
The EU DPP Registry is not simply a database where manufacturers submit identifiers.
According to the Commission's API Integration Guide published on 30 October 2026, the Registry accesses the Digital Product Passport through its unique product identifier URL and validates the retrieved content during registration.
The Registry does not retain the complete fetched passport content.
But the passport must be accessible and satisfy the applicable validation requirements.
That creates a practical risk.
A manufacturer could have:
- a functioning QR code;
- an accessible product information page;
- a complete internal product database;
- successful validation within its chosen industry framework;
- working ERP and supply-chain integrations.
Yet the DPP could still fail the Registry's validation process if the required European representation is missing, incomplete, incorrectly structured or semantically inconsistent.
The Registry integration guide also specifies that registration submissions can contain up to 100 DPP items and are processed atomically.
If one item in a submission fails compliance checks, none of the items in that submission is registered.
For organisations planning high-volume Battery Passport registration, a seemingly small implementation issue could therefore create operational delays.
A successful QR-code scan is not proof of successful EU Registry registration.
Likewise, a technically successful API request does not necessarily mean that the registration has succeeded: the final processing outcome must be checked.
5. What does this mean for implementations already underway or completed?
The impact depends heavily on the architecture and maturity of the existing solution.
Scenario A: You have collected the data but have not finalised your DPP software
Your position may be relatively favourable.
Most of the work already completed to collect manufacturing, technical, compliance and supplier information should remain useful.
The priority is to assess missing attributes, identify the correct European representations and align the publishing process before completing the software implementation.
Scenario B: Your ERP and supplier integrations are complete
The integration work is not automatically wasted.
However, you should verify whether the existing data mappings support the newly defined European attributes, value formats and validation rules.
Some changes may be handled within a dedicated transformation layer.
Others may require collecting additional information from the source systems or suppliers. Supplier data gaps are a recurring theme; see Missing Battery Data from Suppliers.
Scenario C: Your passports are already generated and technically validated
Do not assume that the implementation is finished.
Determine which validation framework and version were used.
Then test the actual DPP representation against the Commission's applicable semantic model.
Where gaps are identified, distinguish between formatting changes, missing source data and genuine compliance issues.
Scenario D: You developed a proprietary Battery Passport platform
This situation requires particular attention.
If your underlying data architecture is tightly coupled to a specific industry schema, introducing a second representation may require substantial development.
If your platform uses a flexible internal data model and configurable interfaces, the work may be more limited.
The cost of adapting the solution depends much more on architectural flexibility than on the original choice of standard.
Scenario E: You use a commercial DPP provider
Ask your provider for specific evidence of readiness against the Commission's latest requirements.
A statement that the solution is "EU compliant", "Catena-X compliant" or "BatteryPass-Ready validated" is not sufficiently precise.
Request documentation identifying the model version used, the tests performed, unresolved gaps and the steps required for Registry registration.
Most importantly, establish who is contractually responsible for implementing and financing necessary adaptations.
The key risk is not necessarily having chosen the wrong standard. It is having built an implementation that cannot adapt when the regulatory framework evolves.
6. Could the European model change again before February 2027?
Yes.
And companies should plan for that possibility.
The Commission's first semantic release was published on 30 October 2026, less than four months before the Battery Passport becomes mandatory on 18 February 2027.
The official Semantic Data Guide explicitly defines a versioning framework that supports three categories of changes:
- Patch updates: corrections or clarifications that should remain backward compatible.
- Minor updates: backward-compatible additions, such as new optional attributes or vocabulary entries.
- Major updates: potentially breaking changes, including modifications to mandatory fields, data types or validation constraints.
This versioning mechanism exists precisely because the data model is expected to evolve.
There are also regulatory elements still under development.
As of 2 November 2026, the implementing act specifying access to restricted Battery Passport information is still being finalised. The Commission has indicated that further consultation is expected in October or November 2026.
Additionally, its battery data-point guidance has already undergone several revisions, with version 3.2 published in October.
The Commission has explicitly indicated that this guidance will continue to be updated. Open questions around the February 2027 deadline are set out in EU Battery Passport 2027: What Is Still Unclear.
What could realistically change before the deadline?
Further clarifications to data definitions, adjustments to validation constraints, controlled vocabularies, category-specific applicability rules and technical implementation guidance are credible possibilities.
Changes connected to restricted data access may also affect how systems authenticate users and expose sensitive information.
A complete replacement of the underlying semantic architecture appears less likely, given the publication of version 1.0.0 and the investment in a versioned EU-wide framework.
However, there is currently no basis for guaranteeing that the October release will remain unchanged until February.
Nor should companies assume that every future update will automatically be backward compatible.
The safest approach is not to wait for a supposedly final model. It is to ensure that the implementation can support new model versions without starting again.
7. Five questions every company should ask its DPP provider now
Whether your project relies on Catena-X, AAS, BatteryPass-Ready or a proprietary solution, the following questions deserve clear answers.
1. Which EU semantic model version does your solution support?
Ask for the actual specification version and the date of the last validation.
General statements about European compliance are not enough.
2. Can you demonstrate successful EU Registry validation?
Request evidence from the official Registry testing environment, including the outcome of the registration process.
Passing another validator is useful, but not equivalent to demonstrating successful Registry registration.
3. Can your existing data be transformed without rebuilding your integrations?
A well-designed system should allow product data to be reused across different technical representations.
Ask which changes require new source data and which can be handled by software.
4. What happens when the Commission publishes version 1.1 or 2.0?
Can your system manage changing attribute definitions, versioned schemas and new validation rules?
Will existing passports remain accessible while their representations are updated?
Who is responsible for maintaining compatibility?
5. Who pays for adapting your implementation?
This question is particularly important for companies that have already signed implementation contracts.
Does the agreement include updates to regulatory data models?
Are technical migrations charged separately?
Does the provider commit to supporting newly published European requirements within an agreed timeframe?
These are commercial questions with direct compliance consequences.
8. What should manufacturers do immediately?
The objective should not be to discard completed work.
Instead, companies should carry out a targeted assessment of their current implementation.
A sensible approach starts with five actions.
- Establish the actual technical baseline. Identify the data models, schema versions, validation environments, interfaces and standards currently used.
- Perform a gap analysis against the European model. Compare applicable attributes, data formats, vocabularies, access rules and validation requirements.
- Separate transformation issues from missing data. A format mismatch can often be resolved technically. Missing manufacturing or performance information may require additional supplier involvement.
- Validate real passports end to end. Test representative EV, LMT and industrial battery passports where relevant, including their actual accessible data representations and Registry registration outcomes.
- Introduce version management. Track which specification applies to each passport, which transformations were used and how future changes will be managed.
Importantly, companies should also distinguish between information required in February 2027 and obligations applying later.
According to the Commission's current Battery Passport guidance, certain carbon footprint, recycled-content and due-diligence information requirements will apply according to their separate regulatory schedules.
Preparing for future requirements is sensible. Incorrectly treating every future attribute as mandatory in February 2027 is not.
9. The bigger lesson: compliance cannot depend on one fixed schema
The events of October 2026 illustrate a broader challenge.
Industrial frameworks and European regulatory models evolve on different timelines.
A standard that is suitable for exchanging supply-chain information today may require adaptations to meet new regulatory validation rules tomorrow.
The same challenge will extend beyond batteries as the European DPP framework expands to additional product categories.
This does not make existing standards irrelevant.
Catena-X remains valuable for interoperable automotive data exchange.
AAS remains valuable for industrial digital twins.
BatteryPass-Ready remains valuable for data preparation and testing.
GS1 standards remain important for globally interoperable identification and digital access.
The objective should be to make these technologies work together, while keeping the regulatory DPP representation aligned with the applicable European specifications.
The most resilient DPP architecture is not the one that assumes a single schema will never change. It is the one that can accommodate change without disrupting production, replacing identifiers or rebuilding every integration.
10. How GoodsTag helps companies navigate the transition
At GoodsTag, we believe Digital Product Passport compliance should not require manufacturers to redesign their entire IT environment whenever European technical requirements evolve.
Our API-first Digital Product Passport platform is built around a flexible Digital Twin architecture, allowing product information to be collected, managed and published across different systems and use cases.
GoodsTag supports integration with existing ERP, PLM and supplier data processes, configurable product attributes, controlled access to passport information and lifecycle updates.
The platform also includes capabilities for cryptographic data integrity, passport version history and independent third-party backup.
This architecture provides the foundation for adapting data representations, extending validation rules and supporting evolving requirements without unnecessary disruption to established business processes.
As the EU publishes new semantic models and technical guidance, GoodsTag supports customers in assessing the implications, identifying required changes and preparing the appropriate implementation and validation steps.
Our objective is not to force companies to abandon existing investments in Catena-X, AAS, GS1-based infrastructures or other technologies.
It is to help them connect those investments to a compliant and maintainable Digital Product Passport approach.
Already using another DPP solution? You can still ask GoodsTag to review it.
Not every company needs to replace its existing provider.
Sometimes, what is needed first is an objective technical and regulatory gap assessment.
GoodsTag offers standalone DPP readiness and compliance assessments for companies that have already developed, purchased or started implementing a Battery Passport solution.
This assessment can cover:
- Existing architecture: evaluation of the chosen standards, data models, integration approach and interoperability strategy.
- EU semantic model compatibility: comparison of existing DPP structures and data against the relevant European requirements.
- Data completeness and applicability: identification of missing information, incorrect mappings and potential validation issues.
- Registry readiness: assessment of identifiers, accessible DPP representations, registration workflows and available validation evidence.
- Future adaptability: evaluation of how the solution can support subsequent European model versions and regulatory developments.
- Remediation roadmap: a prioritised list of actions to address gaps before the relevant compliance deadlines.
These assessments can be conducted as standalone engagements, including when a company intends to continue using its current DPP provider.
GoodsTag is also a DPP technology provider, and any review should be understood as an evidence-based technical assessment, not an official EU certification or a substitute for formal legal advice.
Where appropriate, we can help manufacturers and their existing technology partners implement the necessary improvements.
Your Battery Passport may be built. Is it ready for the EU Registry?
If you have already invested in a Battery Passport implementation, the right next step is not necessarily to start over.
It is to verify what you have built.
Before February 2027, find out whether your existing approach meets the latest European requirements, where the gaps are and how to address them.
Sources
- Regulation (EU) 2023/1542 - Batteries and waste batteries
- Commission Implementing Regulation (EU) 2026/1778 - DPP Registry
- European Commission - DPP Resources and Technical Documentation - includes the Semantic Data Guide, semantic artifacts and API Integration Guide published on 30 October 2026
- European Commission - Battery Passport FAQ
- Catena-X - Digital Product Passport
- IDTA - Digital Battery Passport Specifications
- BatteryPass-Ready - Resources
- CIRPASS-2 - DPP Ontologies
- GS1 Digital Link Standards
Last regulatory review: 2 November 2026. European requirements, semantic artifacts and guidance may evolve. Readers should always check the latest official publications. This article is not legal advice.
