How do identifiers link a battery, its model and its parts into one record?

One battery can carry several identifiers at once: an identifier for the model it belongs to, an identifier for the individual battery, identifiers for the modules or cells inside it, and sometimes an identifier carried over from an earlier life. A scan must land on exactly one record, and that record must show how the identifiers relate without merging two batteries or splitting one battery in two. The structure that holds the relationships is an identity graph: a small map in which each identifier is a point, and each link between points states what kind of relationship it is.

The graph matters because batteries change shape over life. Modules are replaced, packs are split, cells are harvested for a second life pack, and a battery that began as one unit can end as parts of several. Without a graph, each of those events creates a new record that floats free of the original, and a later reader cannot tell whether two records describe two batteries or one battery twice.

What points does the graph contain?

The graph contains four kinds of point. The model point stands for every battery built to one design: one manufacturer, one model identifier, one set of declared values. The unit point stands for a single physical battery: one serial identity, one manufacturing date, one history. Component points stand for modules, cells or subassemblies that carry their own identifiers inside the unit. Event points stand for dated happenings recorded against a unit: a repair, a status change, a transfer, a test result.

Each point carries only the facts that belong to it. Declared capacity belongs to the model point, because it is a property of the design. A measured state of health belongs to the unit point, because it describes one battery at one date. A replaced module belongs to a component point linked to the unit for the period it was fitted, not forever. When a fact is attached to the wrong point, later readers draw wrong conclusions: a model average read as a unit measurement, or a single unit’s fault read as a model defect.

What do the links mean?

Links carry meanings, and the meaning must be written on the link. A unit is an instance of a model. A component is fitted to a unit for a stated period. A unit is succeeded by another unit after a remanufacturing operation. A unit is split into components that enter other units. Each meaning has different consequences for a reader: an instance link means the model values apply unless a unit value overrides them; a succession link means the new record inherits the history and states the operation that created it; a split link means the original unit record closes with a list of where its parts went.

The graph must also state when a link ends. A component removed from a unit keeps its own history, and the link to the old unit is marked ended with a date, not deleted. Deleting ended links rewrites history. A reader who opens the unit record after the removal should see that the component was fitted, when it was removed, and where it went next, in sequence. The sequence is the evidence; a graph that shows only the present arrangement cannot support a question about the past.

How do namespaces keep identifiers apart?

An identifier is only unique inside its namespace: the issuing scheme, the issuer and the rules that govern it. Two batteries can carry the same serial number under different issuers, and two schemes can issue identifiers that look alike. The graph therefore records the namespace with every identifier: the scheme, the issuer identifier and the identifier value, together. A bare serial number without its namespace is not an identifier; it is a fragment that cannot be resolved safely.

Article 77(3) refers to ISO/IEC 15459 standards or equivalent standards for the QR code and unique identifier. In practice that means the identifier carried by the code follows a recognised issuing scheme, so a reader’s system can tell which namespace it belongs to before it tries to resolve it. The namespace record also states who may issue identifiers under it, how collisions are prevented, and how the namespace survives a change of issuer. A namespace with no named issuer and no collision rule is a hope, not a system.

What happens when a battery is repaired or remanufactured?

Repair and remanufacturing change the graph in different ways, and the difference must be visible. A repair keeps the unit point and adds event points: the work done, the parts fitted, the tests passed, the date. The unit identifier does not change, because the battery remains the same battery. A remanufacturing operation that creates a new battery identity closes the old unit point with a succession link and opens a new unit point that inherits the relevant history by reference, not by copying values that no longer describe the new battery.

The test for the graph after either operation is a scan test: scan the battery, reach one record, and read a history that accounts for every identifier the battery has ever carried. If the scan reaches two records, the graph has split the battery. If it reaches a record with no mention of the operation, the graph has hidden a life stage. Either failure misleads the next reader, whether that reader is a buyer, a service technician or a recycler deciding how to handle the battery.

How is the graph checked?

The graph is checked by walking it. A checker picks a unit identifier, follows every link, and confirms that each link resolves, each point carries the facts it claims, and no point is orphaned. Orphaned points are identifiers that appear in a record but lead nowhere: a component with no unit, a model with no units, an event with no battery. Orphans usually appear after a migration, a manual edit or a system change, and they are found by the walk, not by looking at the record that happens to be open.

The walk is repeated on a sample after every migration and after every bulk import, and the results are filed with dates. A walk that finds no orphans on a small sample proves little; the sample should cover each namespace in use, each model family and each life stage. The filed result states the sample size, the namespaces walked and the orphans found, so a later reviewer can judge whether the check was real.

What does a good graph give a reader?

A good graph gives a reader a single answer to the question which battery is this, and a traceable path from that answer to every fact in the record. The reader can start at a scan, reach the unit, step up to the model for declared values, step down to components for fitted parts, and step through events in date order, without ever wondering whether two records describe the same battery. That path is what makes the passport a record of a battery rather than a pile of documents that happen to mention one. Building it is a small amount of structure, maintained with discipline, and it repays that discipline every time a battery is sold, serviced, repurposed or recycled.

This guide gives general educational information only and is not individual legal advice. A reader with a specific battery or system decision should check the current Regulation text and any applicable delegated or implementing act, as checked on 28 October 2026, before acting.