What the QR code does not contain: limits of the symbol on the battery

A QR code on a battery contains a short payload that points to a record. It does not contain the record, and the list of what it does not contain is as important as the list of what it does contain, because readers routinely overread the symbol. A code that is scanned and that opens a page is sometimes treated as if the page were in the code, as if the code proved the page was current, or as if the code proved the battery was compliant.

None of those inferences follows from the symbol. The symbol proves that a printed pattern decoded to a payload. Everything beyond that comes from the record system behind the payload, and must be checked there.

Does the code contain the passport data?

No. The code contains a pointer, normally a URL with the unique identifier. Passport data, including model fields, unit history, carbon and recycled content declarations, detailed composition, dismantling information and test results, lives in the record system. The distinction is not a technical detail. It decides what happens when data changes, when a code is damaged, and when access is restricted. Data in the record can be updated, versioned and tiered. Data in a printed code cannot. A reader who believes the code contains the data will expect the data to be available offline, to be unchanged since printing, and to be visible to anyone who scans. Each expectation is wrong for a passport record, where currency, versioning and tiering are essential. The code is a key. The record is the room the key opens.

Does the code contain measurements or history?

No. State of health values, performance measurements, repair entries and status changes are unit history in the record, added over time. The code was printed before that history existed, and cannot contain it. A code printed at production cannot contain a measurement taken years later, a repair performed after sale, or a status change at end of life. A reader who scans a code and sees no history in the public tier must not conclude that no history exists, because unit history sits in the authorised tier. A reader who scans and sees history must check the dates, because history shown is history as recorded, not history as it stands at the moment of scanning if the record has not been updated. The code is fixed at printing. History is not.

Does the code contain restricted detail or proof of compliance?

No. Restricted detail in Annex XIII points 2, 3 and 4 is held behind access control in the record system. The code does not bypass that control, and the code does not contain the detail in encoded form. A reader without authorised access who scans a code sees the public tier only, and the absence of detail in that view proves nothing about the existence of detail in the record. The code also does not prove compliance. Compliance is a conclusion on the full evidence, including technical documentation and test reports in the authority tier. A code that resolves to a record, even a complete public record, is not a certificate, not an approval, and not a guarantee. The table below summarises the negative catalogue.

Does the code contain personal data or tracking information?

The code payload should not contain personal data, tracking parameters, session codes or marketing identifiers. A payload that contains a session code will fail when the session expires. A payload that contains tracking parameters creates a privacy question and a denser symbol. The resolver may log scans for operational purposes, such as detecting resolver failure or abuse, but scan logging is a system function, not a property of the code, and it should be governed by the applicable data protection rules. A reader who inspects a decoded payload and finds personal data or tracking parameters should treat the code as suspect and should verify the resolver domain before opening the address. A well formed passport payload is short, stable and impersonal: an identifier and a resolver, nothing more.

Does the code contain a warranty or a service promise?

No. A QR code contains no warranty, no service promise, no recall notice and no instruction to return a battery. Warranties and service promises are contractual and commercial matters, stated in the sale documents and the accompanying information, not in a data carrier. A recall notice is a corrective action communicated through the chain and through authorities, not encoded in a code printed before the recall existed. A reader who scans a code and sees a public view must not infer that the battery is under warranty, that a service is available, or that no recall affects the battery. Those questions require checking the sale documents, the operator communications, and authority notices separately. The code opens the record. The record does not answer every question about the battery, and the reader should not ask it to.

What should a reader conclude from a code alone?

From a code alone, a reader can conclude only that a symbol is present, that it decodes to a stated payload, and that the payload names an identifier and a resolver. Every other conclusion requires opening the record, checking the tier, checking identity, and checking the fields. That restraint is not scepticism for its own sake. It is the correct reading of a pointer. This guide gives general educational information only and does not give legal advice for a particular battery, code or record.