In the industrial battery projects we run at Minespider, one question comes up more frequently than almost any other:
What, exactly, carries the battery passport?
For an electric-vehicle battery, the answer is usually straightforward. There’s a pack, it’s bound to a vehicle, and the passport follows it. Yet, the industrial batteries we work on rarely provide such straightforward use cases.
A system is built from modules. Modules form packs. Packs sit in racks. Racks sit in containers. A container is sold as a complete energy-storage system, and then, over a life that can run a decade or more, individual modules and packs get replaced, repaired, moved between installations, sold on as spare parts, or given a second life somewhere else entirely.
So when the EU Battery Regulation requires a Digital Battery Passport, where should that passport live? At the module, the pack, the full system, or the container?
This is what we call Battery Passport granularity. For the industrial manufacturers we work with, it is one of the first real decisions to make ahead of the 18 February 2027 mandate; because it determines almost everything that follows, from where you print a QR code to how much your passport data is actually worth once the battery is in the field.
Why granularity matters for Industrial Battery Passports
Battery Passport granularity is the level at which a battery is digitally identified, tracked, and updated. In plain terms, it answers one question: which physical object does this digital passport belong to?
In our projects, that single choice ends up shaping:
- which Unique Battery Identifier is used, and which QR code is printed where;
- which data fields apply;
- which supplier data you need to collect;
- how lifecycle events (repairs, replacements, ownership changes, etc.) are recorded;
- who can access what, and how;
- how well the whole workflow scales from a pilot to full production.
For industrial batteries the stakes are higher than for most products, because the thing you place on the market is often not a single fixed object. It is a configurable system of replaceable parts. What we see, again and again, is that a granularity model built for a small pilot works fine right up until the first real service event, spare-part sale, or second-life resale, at which point the structure often starts to strain.
If you get it right the passport becomes a durable data asset; a record that service partners, recyclers, customers, and increasingly the trading partners and AI systems evaluating your product can all rely on. If you get it wrong, you inherit a structure you have to rework later, usually at the worst possible time.
While the regulation sets the scope, implementation is still up to you.
Under the EU Battery Regulation (Regulation (EU) 2023/1542), Battery Passports are mandatory from 18 February 2027 for:
- EV batteries;
- LMT (light means of transport) batteries;
- industrial batteries over 2 kWh placed on the EU market.
For industrial batteries, that covers a wide field: stationary energy-storage systems, containerised battery systems, mobile industrial power, commercial and backup storage, and other large-format batteries used in professional settings.
The EU Regulation tells you which categories are in scope. It does not tell you how the requirement maps onto your specific product architecture. That interpretation is where we see the granularity question become real, and in the workshops we run with clients, it is never abstract for long. The questions that surface are always the same:
- If you place a complete containerised system on the market, is the passport the container?
- If that container holds 48 packs, do the packs need their own records?
- If those packs are replaced during service, how is their history preserved?
- If a module is sold on its own as a spare part, does it need its own identifier?
- If dynamic data arrives from a system-level BMS, how does it connect to component-level records?
These are the questions industrial battery teams are working through right now, and the ones we spend most of our time on early in a project.
The four common passport levels
Across the projects we've supported, most industrial battery cases settle on one of four models:
Module → Pack → System / Rack → Container
Each has a logic to it and each also has a trade-off. The right choice depends on how the battery is designed, sold, serviced, and changed over time.
1. Module-level Battery Passports
A module-level passport treats each battery module as its own identifiable unit. It makes sense when modules are replaceable, sold as spare parts, moved between systems, refurbished individually, or reused in second-life applications.
This gives you the most detailed lifecycle view. If a module leaves one system and is installed in another, its history travels with it. This matters for the industrial and stationary systems we work on, where modules rarely stay in the same installation for their whole life. It also supports cleaner service and warranty records, and often faster identification of affected components during recalls or technical reviews.
We see the trade-off is volume, and it's the thing teams underestimate most. Module-level tracking means more identifiers, more records, and more linking decisions. A single system can hold dozens of modules, and each becomes a record to manage. You also have to decide how module records roll up into the pack or system above them: a customer scanning the system does not want dozens of module records at once, but a technician or recycler may need exactly that detail later. Module-level tracking is powerful, but only with a clear data architecture behind it.
2. Pack-level Battery Passports
A pack-level passport treats the battery pack as the main regulated object. For many of the manufacturers we work with, this is the practical middle ground. The pack is often where the battery becomes a functional unit, where the serial number is assigned, where the BMS relationship is defined, and where supplier data can be linked.
It gives you a clear physical object for the passport, manageable passport volumes, useful service and replacement history, and easier identifier management than module-level tracking. For companies that import or assemble complete packs and then integrate them into systems, we usually find this is the best balance between regulatory readiness and operational reality.
The challenge we flag early is dynamic data. A system-level BMS often monitors several packs together, which raises a real question: can you accurately attribute State of Health, State of Charge, cycle count, and operating conditions to each pack - or only to the system it belongs to? When the answer is "only to the system" (and in our experience it frequently is) the passport architecture needs to account for that from the start, not halfway through integration.
3. System-level Battery Passports
A system-level passport tracks the complete battery system: a rack, cabinet, storage unit, or integrated industrial power system. It fits when the product is sold and operated as a whole rather than as individual replaceable parts, and it often mirrors how the customer actually experiences the product: they buy the system, install the system, service the system, and scan the QR code on the system.
This is usually easier to implement, because one passport represents one product, with supplier and component data linked behind the scenes. It works well when components are not usually sold separately, packs are not swapped frequently, the system has one main serial number, and the BMS reports at a system level.
The risk we watch for is losing component-level detail. If a pack is replaced, the system passport has to reflect the change — and the removed pack may need its own history if it is repaired, reused, or recycled. System-level tracking also gets harder when components come from different suppliers or batches, or when customers and recyclers need part-level data. A system-level passport can be enough for the public compliance view, but in most cases we still recommend a linked component structure underneath.
4. Container-level Battery Passports
A container-level passport tracks a complete containerised energy-storage system, which is a common setup in grid-scale and large industrial storage, where the product placed on the market includes packs, racks, control systems, cooling, fire suppression, and power electronics.
The question we put to the team is a simple one: is the container the battery, or the housing for many batteries? If it is sold as one complete system, a container-level passport is often the most intuitive access point as it simplifies customer-facing QR codes, installation documentation, and site-level records. And it’s realistic. Expecting a customer to scan and manage dozens of individual pack passports as the main entry point usually is not.
The complexity is internal, and it's where we see container-only approaches come undone. A container may hold many packs, each with its own supplier data, serial number, chemistry, and lifecycle profile. When a pack is replaced, the container passport must update; when a pack is removed and reused, its own history may need to travel with it. For most containerised systems we work on, the strongest model is a container-level public passport connected to pack-level records behind the scenes.
The strongest approach is usually a linked structure
Here's the pattern we land on most often: the best answer is rarely "only module" or "only container." It is a linked passport architecture: a public-facing passport at the level of the product placed on the market, with more granular records underneath for packs, modules, suppliers, and materials.
For example:
Or:
This keeps the customer-facing experience simple while preserving the detail that service, compliance, and circularity depend on. It's also what turns a passport from a static record into usable product intelligence, essentially data that the right people can query at the right level, rather than a single flat page that answers everyone's question badly.
How we help clients choose the right granularity
When we start a project, we don't begin with what the software allows. We begin with how the product actually works. Six questions get a team most of the way there.
1. What is placed on the EU market? A module? A pack? A full system? A containerised unit? A machine containing the battery? A spare part? The passport strategy should reflect the regulated product and your role as a manufacturer, importer, distributor, or economic operator.
2. What is physically labelled? The QR code has to connect to a physical object. If it is printed on the container but packs change inside it, you need a way to update the passport when those internal changes happen. If it is printed on every pack, you need to manage many more identifiers. We map this before anyone orders a single label.
3. What can be replaced? This is one of the most important lifecycle questions, and the one we push hardest on. A rule of thumb we use with clients: if a component can leave the system and continue its life elsewhere, it should be traceable in some form. That doesn't mean a full public passport for every part, but the data architecture should never treat a replaceable component as invisible.
4. Where does the data come from? Passport data may live in ERP, PLM, MES, BMS, supplier files, test reports, or carbon-footprint tools. If data exists at pack level, pack-level passports are practical. If dynamic data only exists at system level, the design has to account for that. This is usually where we spend the first working session.
5. Who needs access to the data? A customer may need a simple public view; a service partner needs repair history; a recycler needs chemistry and dismantling data; a supplier needs access only to its own contribution. Granularity should support permissioned, controlled access as we don’t want to expose everything to everyone.
6. How will the battery change over time? Industrial batteries are repaired, upgraded, moved, repurposed, reused, and eventually recycled. We design the passport for that lifecycle from the beginning, not for the day it ships.
Static and dynamic data make granularity matter more
Granularity becomes especially important once you separate static and dynamic data, and in our experience, this is where a lot of the real design work happens.
Static data: manufacturer details, chemistry, material composition, production location, technical specifications, compliance documents, identifiers — often belongs naturally to a model, pack, or supplier record.
Dynamic data: State of Health, State of Charge, remaining capacity, cycle count, operating conditions, service history, ownership changes, end-of-life status — usually comes from the BMS, the service system, or the operating environment.
The friction shows up when the two live at different levels. The BMS reports at system level. The passport needs pack-level lifecycle data. Supplier documents apply to a module batch. The QR code sits on the container. Service teams replace only one internal component. We see this mismatch on nearly every industrial project, which is exactly why we settle granularity before integration work begins, not after.
A quick decision reference
This is roughly the logic we walk clients through:
The goal is never maximum granularity. It's the right granularity, detailed enough to stay useful across the battery's life, simple enough to actually run.
Three mistakes we see most often
Treating the passport as a PDF. A Battery Passport is a connected data structure, not a digital label. It links physical batteries, identifiers, supplier data, compliance documents, lifecycle events, and access rights. We've seen passports designed as static files survive the first compliance deadline and then fail the first time a component is replaced. Designed as living, connected data, the passport adapts as the battery changes.
Starting with the QR code instead of the data model. Teams often come to us having already decided where the code goes. It's an understandable instinct, but the code is the access point, not the architecture. Before you decide where to print it, you need to know what object it represents, whether that object can change, which internal components need their own history, and what happens after repair, replacement, or repurposing. The real work is the data model behind the code.
Assuming one level solves everything. A single level is fine for a simple product. Most industrial batteries we work on need a layered approach; a container-level public passport with linked pack records for maintenance, or a pack-level passport with supplier data and documents behind it. The right answer is not always more granular (it's more intentional).
Decide granularity before the pilot, not after
If there's one thing we'd tell every industrial battery team, it's this: granularity is not a detail to settle at the end of implementation. It affects data mapping, supplier requests, ERP/PLM/BMS integration, QR and label design, access control, passport templates, API workflows, and service processes. Decide too late and you may build the first version at the wrong level, then have to restructure everything downstream. We've seen teams map their architecture more than once before landing on the right level, and the ones who do it first move much faster afterwards.
The approach we recommend is to start with one battery model. Map the product architecture. Identify the data sources. Decide which object gets the battery passport — then deliberately test what happens when a component is replaced, updated, or transferred. That is where the granularity decision stops being theoretical.
So…module, pack, system, or container?
The answer depends on the product. But the simplest working rule we give clients is this:
Track the battery at the level it is placed on the market and create linked records for any component that needs its own lifecycle, service, supplier, or replacement history.
For some companies that means a pack-level passport. For others, a system-level passport. For containerised storage, a container-level public passport connected to pack-level records. For modular stationary systems, module-level passports or linked module records.
The best Battery Passport structure is the one that still makes sense after the battery leaves the factory because industrial batteries don't stay static. They're installed, used, serviced, repaired, upgraded, moved, repurposed, and eventually recycled and the passport has to follow that reality.
Where Minespider fits
This is the work we do. We help industrial battery manufacturers turn these decisions into practical battery passport workflows; defining which models are in scope, which category applies, which level the passport should represent, and how modules, packs, systems, and containers relate to each other. That includes mapping which data belongs at model level versus individual-battery level, which data is static and which updates over time, which data should be public, private, or restricted, and how QR codes and unique identifiers connect physical batteries to digital records.
Working through the granularity question for your own battery systems? Book a discovery call and we'll help you map it before you build.
Book a Demo
