How does a battery passport record stay available for the life of the battery?

A battery passport must outlive the project that created it. Batteries placed on the market in 2027 will still be in service, in second life use or in recycling queues in the late 2030s, and a reader in 2038 needs the record to resolve, open and make sense. Availability over that span is not a hosting decision made once. It is four separate continuities, each with its own failure mode: the identifier must keep meaning the same battery, the resolver must keep answering, the record format must stay readable, and responsibility must survive the original operator.

Article 78 requires continuity arrangements for the case where the responsible operator ceases activity, and requires the information to remain available. The planning question is practical: what breaks first when a company is sold, a domain lapses, a vendor closes or a format ages out, and what was put in place beforehand so the break does not orphan the record?

What makes an identifier survive?

An identifier survives when it is independent of the things that change. It should not encode a company name that may be sold, a product line that may be renamed, a server address that may move, or a vendor prefix that may lapse. The identifier names the battery; everything else about the battery lives in the record it points to. A reader who meets the identifier ten years later should be able to resolve it without knowing the corporate history of the company that issued it.

Persistence also needs a rule against reuse. An identifier retired with a recycled battery must never be issued again to a new battery, because a reused identifier merges two histories into one record. The issuing system should keep a retired list that is checked before any new identifier is created, and the check should be a blocking step, not a warning that can be clicked past. The retired list is part of the record system, and it is kept for as long as any identifier it contains could still be scanned.

Who answers when the code is scanned in ten years?

Resolution is the service that turns an identifier into a record address. It fails quietly: a domain expires, a resolver service is switched off in a cost review, a redirect chain grows until a scanner gives up. The defence is to separate the identifier from any single domain or vendor from the start, using a resolver arrangement whose continuity does not depend on one company’s billing account, and to test resolution from outside the operator’s own network at regular intervals.

The test that matters is the cold test: a person with no account, no internal access and no prior knowledge scans a code from a battery placed years earlier and reaches the correct record. The test is run on a sample of identifiers from each placing year, not only on the newest batteries, because the oldest records are the ones most likely to have been orphaned by a migration. Each test is dated and filed, with failures given an owner and a deadline. A resolver that has never been cold tested is an assumption, not a control.

How do formats stay readable?

Formats age in two ways: the file format becomes hard to open, and the meaning of the fields drifts. A record stored in a proprietary format that only one vendor’s current software can read is readable today and unreadable after a vendor change. A record whose field meanings changed across three model years, without version labels, is openable and incomprehensible. Both failures are prevented the same way: store the record in an open, structured form, label every value with the schema version and unit it was recorded under, and keep the schema history with the record.

Migration is then a scheduled activity, not an emergency. When a schema version is superseded, the records under the old version are converted, the conversion is checked field by field on a sample, and the original values are preserved in the version history. A conversion that overwrites originals destroys the evidence that the record ever held the earlier values. The migration log states the version moved from, the version moved to, the sample checked and the date, and it is kept with the record, not in a project folder that will be archived separately.

What happens when the responsible operator stops?

Operators are bought, merged, wound up and restructured. Article 78 addresses continuity when the responsible operator ceases activity, and the practical preparation is a succession file: who holds the identifier mappings, who holds the record data and its history, who operates the resolver, and what triggers the handover. The file names a successor or a mechanism for appointing one, states the format in which the data will be handed over, and sets a time limit for the handover to complete.

The succession file is tested by a tabletop exercise, not left as a paragraph in a contract. The exercise asks the successor team to resolve a sample of identifiers, open a sample of records and show the tier views, using only the handover package. Gaps found in the exercise are fixed in the package, and the exercise is repeated after any major system change. A succession plan that has never been exercised is a hope. The exercise record, with its date and findings, is part of the availability evidence.

How is availability measured over time?

Availability is measured as a record, not as a server promise. The measure counts successful cold resolutions of a dated sample, successful openings of records from each placing year, and successful tier checks, over a rolling period. Uptime of a hosting platform is a different number; a platform can be up while a resolver is broken, a format is unreadable or a tier check is failing. The availability record reports the reader’s experience, and it is reviewed with the same seriousness as a safety or quality record.

The review also tracks the slow risks: domains due to expire, certificates due to renew, schema versions approaching retirement, vendors under notice. Each risk has a date and an owner, and the review confirms that the date is still in the future and the owner still exists. A risk with a past date and no owner is an incident waiting for a scan to discover it.

What does a durable record look like from the reader’s side?

From the reader’s side, a durable record looks unremarkable: the code scans, the record opens, the values carry dates and units, the history shows what changed and when, and the public and restricted views match the access rules. Nothing about the experience reveals the migrations, successions and resolver changes behind it. That ordinariness is the achievement. It is produced by treating availability as a dated, tested, owned property of the record, reviewed on a cycle, rather than as a property of the system that happened to create it. When the next change comes, the record should survive it without a rescue project, because the rescue was planned before the change arrived.

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.