How is a battery passport system put together?

A battery passport system is not one database. It is a set of parts that pass a question along: a scan arrives, an identifier is recognised, the right record is found, the reader’s access tier is checked, and only then is information shown. Each part can be built, replaced or moved separately, and the system stays sound only when the boundaries between the parts are explicit. A single store that holds everything and serves everyone is simpler to draw and harder to keep honest over a battery life of ten years or more.

The architecture question is therefore a question about separation. Source systems hold the facts. The passport service assembles those facts into the record shape Annex XIII requires. Identifier resolution turns a scanned code into a record address. Access control decides which fields a given reader may see. Presentation renders the permitted fields. When a failure happens, the boundary that failed should be visible in the error, not hidden inside one large system.

What lives in each part of the system?

Source systems are the places facts already exist: production records, test laboratories, supplier portals, warehouse systems and service tools. They are not passport systems, and they should not be reshaped to look like one. The passport service reads from them on a schedule or on an event, records what it read and when, and keeps the source reference with each value. A value without a source reference is a claim the passport cannot defend.

The passport service holds the assembled record: model information, individual battery information, status history and the links between them. It owns versioning, so a corrected value supersedes rather than erases the earlier value. Identifier resolution is a separate function: given an identifier, it returns the current address of the record. Access control sits between resolution and presentation, filtering fields by tier before anything is rendered. Presentation is the thinnest part; it shows what it is given and adds nothing of its own.

How do the parts talk to each other?

The parts talk through defined interfaces, not through shared tables. The interface between source systems and the passport service states the field, the unit, the format and the update trigger for each value. The interface between resolution and the passport service states the identifier form and the response when an identifier is unknown, retired or duplicated. The interface between access control and presentation states the field list for each tier in advance, so presentation never has to decide on the fly what a reader may see.

Interfaces need versions of their own. When a source system changes a field name or a unit, the interface version changes, and the passport service records which version each value arrived under. A system that reads directly from another system’s internal tables inherits every internal change without warning. The test for an interface is whether one side can be replaced, upgraded or moved without the other side noticing, apart from the version label.

Where does a failure show up first?

Failures show up at boundaries, and the architecture should make that visible. If resolution fails, the scan returns a clear unknown identifier response, not a blank page or a different battery’s record. If the passport service is unavailable, the response should say the record is unavailable, with a retry route, rather than showing stale information as if it were current. If access control fails, the safe response is to show less, never more: the public tier only, until the tier check works again.

Each failure mode needs an owner and a check. Resolution failures belong to whoever controls the identifier namespace and the resolver. Record unavailability belongs to the passport service operator. Tier failures belong to access control. A single incident log that mixes all three hides which part broke and delays the fix. The readiness question for each part is the same: what does a reader see when this part alone is down, and who is paged?

What happens when a supplier or vendor changes?

Vendor change is an architecture test, not a procurement event. If the passport service is replaced, the new service must import the record history, the identifier mappings and the access rules, and prove by test that every identifier still resolves to the same record with the same tier views. If a source system is replaced, the interface version changes and the values are rechecked against the new source, with differences listed rather than silently accepted.

The contract that matters is the exit contract, written before the entry contract is signed. It names the export format, the identifier list, the history depth and the time allowed for migration. A system whose records can only leave through the vendor’s own tooling has a single point of failure in the vendor’s future. The architecture record should state, for each part, what would be needed to move it, and the date that statement was last tested.

How is the architecture recorded?

The architecture is recorded as a diagram with a register behind it. The diagram shows the five parts, the interfaces between them and the owner of each part. The register lists each interface, its version, its field list, its update trigger and its last test date. A diagram without a register is a picture; a register without a diagram is hard to follow. Together they let a new engineer, an auditor or a successor operator understand the system without interviewing the person who built it.

The register is reviewed when any part changes, and at least once a year. The review asks three questions: does every identifier still resolve, does every tier still see only its fields, and does every value still carry a source reference and a date? A review that answers yes from memory rather than from tests is not a review. The answers, with test evidence, are filed with the record history.

What should not be built into one part?

Presentation should not hold business rules, access control should not hold record content, and resolution should not hold passport data. Each shortcut saves time once and costs clarity every time the system changes. A presentation layer that filters fields by hiding them in the browser has not restricted access; it has decorated it. A resolver that returns record content has become a passport store without the controls a store needs. The architecture holds when each part does one job and the interfaces between them are written down, versioned and tested. That is the whole discipline, and it is enough to build on.

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.