Data governance framework and system architecture: Digital battery passport

Data governance framework and system architecture: Digital battery passport Maria Bashir1, Bikesh Shrestha1, Shailendra Singh1, Martin Thomas Horsch1,2, and Heinz A. Preisig3 1Norwegian University of Life Sciences, Material Theory and Informatics, 1432 ˚ As, Norway, 2UKRI STFC Daresbury Laboratory, Scientific Computing Department, Warrington WA4 4AD, UK 3Norwegian University of Science and Technology, Department of Chemical Engineering, 7491 Trondheim, Norway [email protected] Abstract. Digital product passports (DPPs) are persistent and interoperable digital records that support transparency and regulatory compliance throughout a product’s lifecycle. They are mandated by EU regulations. DPP systems that are compliant with regulations will require trustworthy governance with clear accountability, enforceable policies, and verifiable and immutable records. This work proposes a DPP governance framework by deriving requirements from the Ecodesign for Sustainable Products Regulation and the Batteries Regulation. We operationalize the framework by integrating it into a single DPP system to demonstrate policy-to-implementation traceability. The DPP system ensures role-scoped write privileges, tier-filtered disclosure, immutable frozen versions with cryptographic signatures, and persistent identifiers with resolvable QR codes. It implements six roles, three visibility tiers, five types of enforceable controls, and verified traceability. As a proof of concept, it is applied to the DPP for vanadium redox flow batteries. 1 Introduction 1.1 The digital product passport Digital product passports (DPPs) move trustworthy product information across organizational supply chains and boundaries [1,2,3]. However, most data estates still suffer from duplicate records, inconsistent metadata, and broken provenance: The “deluge of dark data” [4] is well-documented [5], in particular, in research data infrastructures [6,7,8,9,10]. The DPP requires transparent governance and, therefore, accountable and well-defined roles, such as, in a high-performance computing context, the scientific data officer [5,11]. Information needs to vary across actors and lifecycle stages in battery value chains. Yet, actual data flows are proven to be fragmented and inconsistent, resulting in persistent gaps in diagnostics, life-cycle assessment (LCA) inputs, and end-of-life information – at 2 M. Bashir et al. the same time when credible reuse or recycling decisions must be made [12]. Governance research states the same diagnosis: Without enforceable and observable access controls at runtime, policy alone cannot guarantee quality, entitlement, or provenance [13]. Evidence from public and private data ecosystems shows that integrity and accountability are sustained by strong identification and authentication, validation gates, and auditable logging – not by documents alone [14]. A DPP system is not just a database, but a socio-technical infrastructure that helps coordinate roles and decision rights around product-specific information, so that each participant accesses the appropriate “piece of truth” under justified legal and commercial conditions [15]. Within the scope of the present work, we distinguish governance from management as follows: Governance defines and determines who decides, while management implements those decisions. Following the framework from Khatri and Brown [16], governance comprises five interrelated domains: Data principles, data quality, metadata, data access, and data lifecycle. Principles set the boundaries and direction; quality sharpens expectations; metadata enables interpretation; access regulates exposure; and lifecycle decisions align production, retention, and retirement with governance intent. Prior work in research data infrastructure and interoperability frameworks in materials modelling emphasizes that data principles and metadata are not abstract ideas but operational instruments for governance [17,18]. Beyond these decision domains, governance also functions as a programmatic system with interdependent components ranging from people and principles to standards, security, communication, metrics, and technology, making governance observable and auditable rather than rhetorical. For this purpose, it makes sense to develop formal procedural and process descriptions, which in an AI context are often referred to as pipelines, linking high-level policy to concrete controls for classification, validation, access restriction, lineage, and audit [19]. For batteries, effective governance further depends on role-aligned disclosure [20]. In governance terms, this is stewardship: Infusing the correct data into the proper process, in the right format, under the right conditions, backed by controls that make those duties observable during operation [14]. However, the primary focus in DPP research, including the Digital Battery Passport (DBP), still emphasizes what to include in field lists, schemas, and standardized data models, while focusing comparatively less attention on how auditable governance is specified and enforced, cf. Gianvincenzi et al. [21]. Architecture efforts describe building blocks and interfaces but often ignore the entitlement, release/change control, and assurance patterns to the developer [22]. There is also a gap regarding translating design requirements into enforceable decision rights, and defining the minimum verifiable evidence that access decisions should yield at the point of use [12]. Technology choices cannot substitute governance. DPP legal analysis warns against techno-solutionism and requires explicit coordination for explicit coordination, access-rights management, quality assurance, and supervised curation prior to reuse [15]. Systematic reviews of data governance also report a structural imbalance, as literature places disproportionate emphasis on defining roles/policies/standards while paying the least attention to implementing and Data governance framework: Digital battery passport 3 monitoring practices, which are the exact activities that render governance observable and auditable [13]. Consequently, platforms may succeed at storing the right attributes, yet still fail to indicate entitlement, integrity, and provenance when data are utilized. 1.2 Objectives and contributions Governance is established within a single, role-aware DPP/DBP system designed for policy-to-implementation traceability, linking regulatory policy to technical enforcement, visible to all relevant stakeholders [15]. This approach integrates three reinforcing elements. Initially, a DPP-tailored governance model explicitly assigns roles and decision rights in alignment with visibility, release, and change management, operationalising the roles through the current reference architecture [22]. In addition, a set of assurance controls is issued that compiles these obligations into enforceable mechanisms such as role-scoped access, validation gates, versioned provenance/audit, cryptographic integrity, and persistent identifier/QR code (PID/QR) resolution to bring compliance into action [14]. Finally, a reproducible blueprint is provided, comprising well-defined schemas, role/permission specifications, and verification steps, enabling the potential redeployment of stated governance pattern. Our framework is meant to be lightweight; specifically, unlike other architectures [2], it does not require blockchain technology. 1. Legal and business governance: This layer addresses regulatory compliance and the responsibilities of value chain actors (e.g., economic operators, market surveillance authorities, conformity assessment bodies), in alignment with key EU regulations such as the Ecodesign for Sustainable Products Regulation (ESPR), Batteries Regulation, General Data Protection Regulation (GDPR), and Data Governance Act (DGA). 2. Operational governance: The operational layer defines who performs what tasks throughout the lifecycle of the Digital Product Passport. It includes roles such as manufacturers, data stewards, compliance officers, auditors, and recyclers, each with distinct responsibilities in data entry, validation, approval, and reporting. 3. Technical platform governance: This layer implements the governance model in practice by translating those duties into enforceable controls through authentication/authorization (RBAC), identifier management (PID/QR), validation gates, versioned provenance audit trails, and integrity sealing so that conformance can be verified in operation. 1.3 Regulatory context and governance implications The present DPP framework is grounded in three EU instruments: The ESPR,4 the Batteries Regulation,5and the DGA.6In essence, these establish (i) re4Regulation (EU) 2024/1781, https://eur-lex.europa.eu/eli/reg/2024/1781/oj 5Regulation (EU) 2023/1542, https://eur-lex.europa.eu/eli/reg/2023/1542/oj 6Regulation (EU) 2022/868, https://eur-lex.europa.eu/eli/reg/2022/868/oj 4 M. Bashir et al. sponsibility for passport minimum content, (ii) persistent unique identifier on a physical data carrier, (iii) machine-readable and interoperable formats with accuracy over the specified lifetime, and (iv) broad, free-of-charge read access according to product-group rules alongside restricted write privileges for authorized actors (ESPR Art. 11 and Annex III). These provisions map directly to our platform specifications. The ESPR authorized actors are defined as manufacturers, trade unions, customs authorities, importers, customers, and recyclers. This grounds our RBAC design: Read scopes differ across public actors and authorities; write scopes are limited to responsible economic operators (rEOs) and designated DPP service providers (DPPSPs). The Batteries Regulation mandates a battery passport from 2027 for LMT, EV, and industrial batteries >2 kWh, cf. Art. 77(1) Batteries Regulation. The passport should include model-level and unit-specific information, including usederived data, as defined in Annex XIII, and be kept accurate. Access is tiered: (a) Public; (b) notified bodies, market-surveillance authorities, and the Commission; and (c) persons with a legitimate interest (to be specified by implementing acts). Technical baselines mirror ESPR, for example, interoperability with other DPPs, free-of-charge access, and storage by the authorized provider. In addition to this, DGA imposes neutrality and trust safeguards for data intermediation with no repurposing, fair and non-discriminatory terms, interoperability, and activity logging (Art. 12) and sets conditions for secure processing and crossborder transfers of non-personal data (Art. 31) and this is without prejudice to the GDPR and does not itself provide a legal basis for processing personal data. 2 Data governance framework 2.1 Access and disclosure policy (role-based access control) Access decisions combine role, declared purpose of access, and the product’s visibility tier (Public, Limited, Confidential). Every request is evaluated in light of the actor’s role. Decisions are taken at a policy decision point (PDP) and enforced by a policy enforcement point (PEP), with field-level filtering to serve only attributes admissible for the tier and purpose. Every decision yields an auditable record (role, purpose, tier, allow/deny, and the precise fields delivered), making entitlement and disclosure observable at the point of use. In our governance model, decision rights are constrained as follows. The rEO may create, edit, publish, freeze/unfreeze its own DPPs and read all tiers for owned products, so that no other actor can mutate content or change state. Public authorities (PA) have read access to Public, Limited, and Confidential content but no write privileges. Supply-chain actors (SCA) may append supplier declarations under append-only semantics and otherwise read Public/Limited data; independent operators (INOP) read Public/Limited only. The DPPSP operates and manages the platform with view-only access across Public/Limited/Confidential and does not author, freeze, or version content. The access conditions are: Public - readable by all roles; Limited - readable by rEO, SCA, INOP, PA, and DPPSP; Confidential - readable by rEO, PA, and DPPSP Data governance framework: Digital battery passport 5 Fig. 1. Roleand tier-based access policy for DPP data, visualized as a decision tree only. The rEO may define alternative tier assignments at creation time. Freeze and new-version actions are restricted to the rEO. These constraints are reflected in the RBAC flowchart (Figure 1) and align with generic roles anticipated in the CIRPASS-2 reference architecture [22]. 2.2 DPP lifecycle state machine Figure 2 shows when authorized role holders may change or edit a record and the semantics of those changes. The passport’s core specification alternates between two control states: Editable (vN) and Frozen (vN). The specification can be changed in the Editable state, but only the rEO can edit. A Freeze action (by the rEO) locks and freezes the record, computes and stores a digital signature as a standardized representation of the record, and marks the version as read-only. Any subsequent modification to the specification cannot be applied directly to the original record: The rEO must unfreeze and create a new version (vN+1) from the editable state. Earlier versions become Superseded and remain available as immutable history through the user interface (UI) and the API. Two categories of update do not change the specification: (i) Lifecycle events, and (ii) supplier declarations. These follow append-only semantics on separate 6 M. Bashir et al. Fig. 2. Product state machine with authorized transitions (publish, freeze, unfreeze, new version) bound to role duties tracks and are therefore visible without altering the signed core. Supplier declarations are append-only by supply-chain actors (SCA); lifecycle events are append-only under the owner’s control and do not alter the specification payload sealed at freeze. Read access at any state is still filtered by the tier policy (Public / Limited / Confidential) described in Figure 1. The state machine explicitly encodes the platform’s prohibitions: No role may edit the specification while it is Frozen; non-rEO actors cannot Freeze or create a New Version. In effect, version progression (Editable vN→Frozen vN →Editable vN+1) is both the release process and the assurance mechanism where each Freeze yields a verifiable signature and each version transition yields an changed record, so authorship, timing, and information can be verified. 2.3 Policies and their assurance signals The governance framework is expressed in terms of roles and lifecycle rules and implemented as enforceable policies with corresponding assurance artefacts. Tiered disclosure ensures that only attributes admissible for the relevant visibility tier (Public, Limited, Confidential) are accepted, where each served response is filtered accordingly. Entitlement is enforced as the function of role, declared purpose, and state; for instance, non-authoring actors cannot alter specifications, and any requests outside their scope are denied. Release and change control separate drafting from publication. Passports may be published only after eligibility checks, while modifications to a frozen record will create a new version. Immutability and integrity are guaranteed by sealing the canonical specifica- Data governance framework: Digital battery passport 7 tion at freeze with a cryptographic signature. Provenance is preserved through the append-only ProductEditLog, which records who changed what and when, with human-readable diffs available for inspection. In this way, epistemic metadata [23] for the records can be generated. Identification and resolution are tied to persistent identifiers encoded in International Electrotechnical Commission (IEC) 61406 QR codes, enabling interoperability and consistent lookup across systems [24]. Finally, neutral intermediation is maintained by restricting the platform operator (DPPSP) to view-only duties, never content authoring. These controls make disclosure, authorship, integrity, and lineage directly observable. 3 System architecture 3.1 Layered design We are proposing a three-layer architecture. First, an API layer provides authenticated endpoints for creating and retrieving the product passports. The second, a business-services layer, implements authorization decisions, visibility filtering, versioning, and digital signature workflows. Finally, a persistence layer supported by a relational database that ensures the permanent storage and retrievability of all records in accordance with governance rules. Write operations (create, update, delete) are owned by the owner and validated against the product state (frozen or editable). Read operations uniformly apply role and visibility checks, ensuring sensitive fields are never exposed to unauthorized users. At the user interface level, role-specific dashboards provide differentiated entry points for responsible economic operators, public authorities, supply-chain actors, independent operators, and the DPP service provider. These dashboards are not merely front-ends, but control gateways that verify identity, credentials, and implement role-scoped disclosure, ensuring integration of governance constraints. The application layer hosts the enforcement services. It implements the RBAC and PDP/PEP logic defined in the governance framework (Section 2.1) so that every API call is authorized and filtered by role, purpose, and visibility tier. In line with the CEN/CENELEC JTC 24 DPP draft standard [24], the API exposes machine-readable passport data as JSON over HTTPS/REST (cf. Figure 3). These APIs are designed for organizational interoperability (integration with supply-chain and regulatory systems), technical interoperability (REST/JSON with token-based security), and semantic interoperability (alignment with field lists in Annex III of the ESPR). The platform therefore provides both a humanfacing dashboard and an auditable machine interface, consistent with JTC 24 recommendations on harmonised API gateways and service interoperability [24]. At the persistence layer, the system ensures durability and controlled evolution of product records. All passports, parts, materials, lifecycle descriptors, and supporting documents are stored in a PostgreSQL schema design. Versioning and cryptographic freeze-signing follow the lifecycle policy described in Figure 2. This design reflects the JTC 24 document [24] on persistence and archiving, emphasising immutability, retrievability of old versions, and the need for redundant 8 M. Bashir et al. Fig. 3. Generic HTTPS and REST-based data pipeline for DPP systems storage to support long-term verifiability. Identifiers are resolved via IEC 61406compliant QR codes, which link physical carriers to persistent digital identifiers. Each resolution is logged to provide verifiable evidence of identifier continuity and to meet interoperability and neutrality requirements. 3.2 Data structure and user interface The top-level data structure of a product’s DPP depends heavily on the regulations and standards in place. At the next level, product-specific domain regulations and requirements dictate the data model for the given product. These requirements require a common language, which defines a request for a global, persistent terminology, typically provided by an ontology. This suggests that it may be helpful to ontologize regulatory documents by extracting their concept definitions. At the second level, the product-specifying entities must be ontologized. Within the DigiPass CSA project, an effort has been made to ontologize the text of the ESPR regulation. Establishing such ontologies may plausibly further contribute to making the DPP a viable instrument for regulatory compliance, but it is not a prerequisite for implementing the DPP system. Implementing a product’s data structure is defined by the regulations, which require a technique that supports a tight specification. The shapes constraint language SHACL provides exactly the required structural elements. While it has been generated to check data, we use it to construct the user interface. In the first step, the principal building blocks are defined, like asking for a string to represent an item defined by an ontology. An example could be the producer’s name, a string, or organization number. SHACL, which was designed to define data structures, is well-suited to defining them without fuzziness [25]. For our example, it allows us to define the nature of the data item, like string, integer, dates, Data governance framework: Digital battery passport 9 etc. It provides a way to constrain the range of numerical values, the length of string values, and the format of data items using regular expressions. As SHACL was designed to validate knowledge graphs, it is equally wellsuited for defining data ingest interfaces presented to a user via a web platform. The Data Shapes Vocabulary (DASH) extension was defined in this context, providing a tool for generating user interfaces. Implementations are still very sparse. However, VIPCOAT7and DigiPass CSA8use this technology for their platform implementation. SHACL/DASH operate on a tree structure (shape graphs) with nodes and their properties, and they can be used for multilingual environments. Several sandboxes exist, making the technology accessible.9 4 Conclusion This paper has demonstrated a data governance framework and system architecture for digital product passports that bridges regulatory requirements with enforceable platform controls. Through role-aware access, lifecycle policies, the immutable provenance concept, and PID/QR-based resolution, we illustrated how roles can be translated into evidence visible to regulators, auditors, and industry actors. The result is a blueprint that safeguards integrity and accountability across value chains and provides regulators and industry with a transparent and reproducible governance model. We ensured restricted writes by the responsible operator only, using cryptographic freeze signatures and appendonly supplier and lifecycle event records. We logged tier-filtered responses with recorded decisions, showing that governance rules were enforced. Extending this approach with domain-level and application-specific ontologies and automated validation workflows will be essential to scale these DPP systems across sectors. Future work will also need to evaluate the system of delegated acts (for specific categories of products) that is to be created under the ESPR, as well as the Construction Products Regulation10 (CPR), to the extent that products with cross-sectoral use are considered. Carbon felt materials, for instance, are also used as thermal insulators, in addition to their use as an electrode material. Therefore, they may also have a DPP under the CPR, or ideally, a cross-sectoral DPP that accounts for regulatory requirements from the Batteries Regulation, the ESPR, and the CPR simultaneously. The same logic will apply to materials with a cross-sectoral use in the textiles sector, where the ESPR is relevant as well [3]. At the same time, more detailed DPP requirements are expected from a future revised version of the Textiles Labelling Regulation. Acknowledgment. We acknowledge funding from the EU’s Horizon Europe research and innovation programme through GA 101138510 (DigiPass CSA); coauthors Bashir, Horsch, Shrestha also acknowledge GA 101137725 (BatCAT). 7Platform URL: https://vipcoat-oip.com/welcome 8Platform URL: https://digital-passport.io/ 9URL: https://ulb-darmstadt.github.io/shacl-form/#try-your-own 10 Regulation (EU) 2024/3110, URL: http://data.europa.eu/eli/reg/2024/3110/oj.