A data carrier and a record are different things. The carrier is a printed symbol, a tag, or another physical means of carrying a machine readable identifier. The record is the electronic information held in a system, organised by Annex XIII, with tiers, versions and history. The carrier points to the record. The record does not live in the carrier. Confusing the two leads to a set of predictable errors: a belief that the carrier contains the passport, a belief that updating the record requires reprinting the carrier, a belief that a damaged carrier means a lost passport, and a belief that a readable carrier proves a complete record.
Each belief is wrong, and each wrong belief leads to a wrong action.
What does the carrier contain?
The carrier contains a payload, normally a URL or a structured identifier, that is short, stable and sufficient to resolve to the record. The payload contains the unique identifier, or a reference from which the identifier can be derived, and the resolver address. The payload does not contain composition detail, carbon figures, state of health values, dismantling information or test results. Those fields live in the record, behind the resolver, under access control. A carrier that tried to contain the record would be dense, fragile, unchangeable and insecure: dense because the data volume exceeds what a printed symbol can carry robustly, fragile because a dense symbol is harder to read, unchangeable because printed data cannot be updated, and insecure because printed data cannot be tiered. The pointer design solves all four problems at once, by keeping data in the record and keeping only the pointer on the battery.
What does the record contain that the carrier does not?
The record contains the full Annex XIII information set, in tiers, with version history and unit history. The record contains model fields that change on revision, unit fields that grow with use, and evidence links that allow a claim to be traced. The record can be updated without touching the battery, because the pointer stays the same while the data behind it changes. A state of health entry added years after placing does not require a new carrier. A correction to a model field does not require reprinting. A status change does not require a new code. The record is a living document in the sense that it accumulates history, and the carrier is a stable pointer in the sense that it never needs to change to reflect that history. Stability of the pointer and change in the record are complementary, not contradictory.
Why does the distinction matter for updates?
Updates illustrate the distinction most clearly. When a record is updated, the carrier on the battery stays the same, and the next scan reaches the updated record. When a carrier is reprinted, because the original was damaged, the new carrier must encode the same payload, so that it reaches the same record. An update to the record that is accompanied by a new carrier with a new identifier is not an update. It is a new record, and it breaks history unless linkage is recorded. A reprint that encodes a different payload is not a repair. It is a redirection, and it must be treated as a record event with a reason and a check. The distinction gives operators a simple test: if the identifier changed, something more than an update or a reprint has happened, and the record should explain what.
What errors follow from confusing carrier and record?
Confusion produces four errors. First, a reader assumes that a code that scans proves a complete record, when scanning proves only resolution. Second, an operator reprints codes after every record update, creating identifier churn and history breaks. Third, an operator assumes that a damaged code means the passport is lost, and creates a duplicate record instead of replacing the carrier. Fourth, a reader assumes that data printed near the code, such as capacity on a label, is the record, when labelling and record are complementary sources that must agree but are not identical. Each error is prevented by naming the carrier and the record separately in every procedure, every test and every failure report. Language discipline is a control, not a style preference, in record systems.
What does the distinction table show?
| Subject | Carrier | Record |
|---|---|---|
| Form | Printed symbol or tag on the battery | Electronic information in a system |
| Content | Short payload, identifier and resolver | Full Annex XIII set, tiers, versions, history |
| Change | Stable, reprinted only when damaged, same payload | Updated over life, history accumulates |
| Access | Readable by any scanner | Tiered, authentication where required |
| Failure | Unreadable symbol, wrong payload | Missing field, stale value, broken link |
What should a reader say after a scan?
A reader should say that a scan reached a record, name the identifier, name the tier viewed, and name the date of viewing. A reader should not say that the scan showed the passport as if the code contained it, and should not quote a value from the record as if it were printed on the battery. Precision in describing what was seen supports precision in relying on it. This guide gives general educational information only and does not give legal advice for a particular battery, carrier or record.
Sources & further reading
- Regulation (EU) 2023/1542, consolidated text, Articles 13 and 77 ↗
- European Commission, Batteries ↗
- Regulation (EU) 2024/1781, ESPR digital product passport framework ↗
Source links point to primary materials and further reading, including commercial implementation resources where cited. This introductory guide does not replace the legislation.