Changing specifications and versions: how a passport handles a revised battery model

A battery model changes over its production life. A supplier changes, a cell is revised, a capacity rating is corrected, a dismantling sequence is improved. Each change raises the same record question: is this a new version of the model, a correction to the existing record, or a change that creates a new model altogether. The answer decides which units link to which record, which declaration covers which units, and which dismantling detail a repairer should use.

A record system that overwrites the old specification with the new one, without a version history, destroys the ability to answer those questions for units already placed on the market.

What counts as a specification change?

A specification change is a change to a fact stated in the model layer: chemistry, rated capacity, voltage, weight, composition, performance values, dismantling detail, or safety measures. A change in a supplier that does not alter a stated fact may still be a change in the evidence behind a fact, and the register should record it even when the model layer value stays the same. A change in packaging, labelling artwork or documentation layout that does not alter a stated fact is not a specification change for passport purposes, although it may matter for labelling compliance. The test is whether a reader who relies on the model layer would be misled by the old value for a unit made after the change. If the answer is yes, a version change is required. If the answer is no, a note in the register may be sufficient, with the reason stated.

How is a version recorded?

A version is recorded with a version identifier, an effective date, a description of what changed in neutral terms, and a link to the supporting documentation. The version identifier should be simple and sequential, such as version 1, version 2, with a date, rather than a code that requires a key to interpret. The effective date is the date from which units are produced to the new specification, or the date of placing on the market for the first unit to the new specification, stated clearly so that the boundary is not ambiguous. Units produced before the effective date keep their link to the earlier version. Units produced after the effective date link to the new version. A version record that states only that a change occurred, without an effective date, leaves the boundary open and forces every later reader to guess which units are affected.

What happens to the declaration and the passport on a version change?

A version change that alters a characteristic covered by the EU declaration of conformity requires assessment of whether a new declaration, a revised declaration, or a new conformity assessment is needed, under Articles 17 and 18 and the conformity assessment procedure in Annex VIII. The passport record must reflect the declaration position for the version: the declaration reference for units of that version, the date of the declaration, and the conformity assessment procedure applied. A passport that shows a single declaration reference for all versions, where versions have different declarations, misstates the position for at least one version. The Blue Guide on the implementation of EU product rules provides general guidance on substantial modification and on the effect of changes on conformity, and the operator should read that guidance with the Battery Regulation text, not as a substitute for it. Version and declaration must move together in the record.

How are corrections distinguished from versions?

A correction fixes a wrong statement of an existing fact. A version records a new fact. A misprinted capacity value that never reflected the tested battery is a correction. A revised capacity rating that reflects a new cell is a version. A wrong chemistry description that misnamed the cathode material is a correction. A new chemistry for a revised pack is a version. The distinction is recorded in the version history, with the prior value retained and the reason stated in neutral terms. A correction does not create a new model layer for future units unless the corrected fact is also the fact for future units, in which case the correction and the version may coincide and the record should say so. A system that labels every change a correction hides real specification changes. A system that labels every correction a version creates unnecessary model layers and confuses readers.

What does the version table illustrate?

What should a reader check on a revised model?

A reader should check the version identifier, the effective date, the declaration reference for that version, and the unit production date against the version boundary. A unit produced before the boundary should link to the earlier version. A unit produced after the boundary should link to the new version. A unit with no production date, or a record with no version history, cannot be checked against the boundary, and the reader should treat the specification as unverified for that unit. This guide gives general educational information only and does not give legal advice for a particular model, revision or transaction.