From 18 February 2027, digital product passports (DPPs) for batteries will move from regulatory text to operational reality. In our first blog post, we showed how we translate legal and normative requirements into specific user stories and testable scenarios. In the second, we described how these user stories feed into a testing environment that helps organizations validate their implementations.
This third article looks at the bigger picture: the battery passport ecosystem as a whole and how we are developing an enterprise model that reflects this complexity while helping organizations navigate it.
A Complex Ecosystem by Design
The battery life cycle stretches from mining and refining, through cell, module, and pack production, to first use, potential second life, and finally dismantling and recycling. Our practical focus in BatteryPass‑Ready starts at the moment when the battery is placed on the market and the battery passport is published. The upstream value chain and processes before passport issuance remain out of scope for the test environment, but they still shape the data that must be reflected once the passport exists.
From that point onward, the passport is not a static artefact. It is created when the battery is placed on the market, updated over time as technical and usage data changes, and may be replaced or newly created when batteries are repurposed or remanufactured. Eventually, the passport ceases to exist when the battery reaches its end of life.
Throughout this journey, a wide range of actors interact with the passport. Economic operators must provide and consume data via their internal systems. The EU registry functions as a central service. Third‑party services, such as backup DPP service providers, support the operation of the ecosystem. Oversight is provided by enforcement and market‑surveillance authorities.
Even with the upstream stages excluded from our test environment, the ecosystem within scope remains highly complex. There are multiple actors with different roles and responsibilities, distributed systems that must communicate reliably, varying access rights, and a mix of static and dynamic data that must remain consistent over time. Our test environment must capture this complexity rather than relying on a simplified, unrealistic model.
Why an Enterprise Model Is Needed
Standards and regulations define what a compliant DPP system must achieve, but they do not fully describe how the overall ecosystem behaves as a living system. Organizations therefore face very practical questions: Where do my responsibilities begin and end in the battery passport lifecycle? Which other actors and systems does my implementation need to interact with, and in what way? How do registry, economic operators, third‑party services, and authorities fit together in one coherent picture?
An enterprise model helps to answer these questions.
By “enterprise model” we mean a structured representation of actors and roles, processes and interactions, information flows and responsibilities, interfaces and technical touchpoints, and the regulatory constraints that frame them. The aim is not to add abstraction for its own sake, but to provide a map of the ecosystem that mirrors its full complexity while still guiding organizations toward specific design, implementation, and testing decisions.
User Stories as Building Blocks
The user stories introduced in our first blog post form the starting point for this enterprise model. These stories describe realistic business processes such as placing the battery on the market, updating battery passport data, or reading access‑restricted and public data. Each user story spans multiple actors, links regulatory and technical requirements, and exposes assumptions wherever standards leave room for interpretation.
This turns an isolated list of user stories into a structured, end‑to‑end view of the ecosystem: a network of processes that together define how the battery passport should behave in practice.
What the Enterprise Model Captures
The enterprise model we are working on is designed to be detailed enough to reflect reality, but still usable for both technical and non‑technical stakeholders.
The model includes a technical integration perspective. It links functional processes and roles to concrete integration aspects such as required API operations for creating, reading, updating, and deleting passports, authentication and authorization patterns between actors, backup and recovery interactions, and connections to central services such as the EU registry. This link between process and technology is essential for aligning system architecture decisions with regulatory expectations and ecosystem needs.
The enterprise model is not an abstract exercise separate from the testing environment described in our second blog post. Instead, it is a practical tool that directly feeds into test design and implementation planning.
Organizations can use the model to define the scope of their systems. By locating themselves within the actor landscape, they can see which user stories and modules are relevant to their role and which are not. When existing systems and processes are mapped onto the model, gaps and unclear responsibilities become visible: missing capabilities, interfaces that need to be designed, or interactions that have not yet been considered.
In this way, the enterprise model turns a complex landscape of actors, APIs, and responsibilities into an organized framework that supports both architectural decisions and day‑to‑day validation work.
What’s next
The battery passport ecosystem will continue to evolve as final standards are published, existing ones are refined, and real‑world implementation experience accumulates. For that reason, our enterprise model is designed to be iterative. It is built on user stories that can be refined or expanded. It explicitly incorporates assumptions, which are documented and revisited as standards develop. And it can be updated as regulatory and technical frameworks mature.
As BatteryPass‑Ready progresses, the enterprise model and the testing environment will evolve together. The user stories and the model define what needs to be tested and the testing environment operationalizes these definitions into executable test procedures.
Our enterprise model aims to provide the understanding: A structured way to navigate complexity and guide organizations from regulatory requirements, through user stories and testing, toward robust and interoperable battery passport implementations.
Patrick Gering
Fraunhofer IPK
