Battery Passport QR Codes
Battery Passport compliance is operational software. The QR code is only the access mechanism. The real requirement is a reliable digital record that is identifiable, accessible, permissioned, version-controlled, and auditable over the battery lifecycle.
What the QR code is and isn't
The QR code is not the passport. It is a pointer that allows an authorized party to access the passport record for a specific unit. Your implementation must ensure the QR code resolves to the correct unit record, reliably, over time.
Plan for damaged labels, replacements, and counterfeits. Treat the physical QR code as a field interface that can fail, while the unit identity must remain stable.
| Element | Purpose | What must be stable |
|---|---|---|
| Unit identifier | Uniquely identifies the physical battery unit | Should not change across service, reuse, and EOL |
| QR code content | Encodes a reference to retrieve the passport record | Must resolve correctly; may be re-issued if label is replaced |
| Passport record | Stores model and unit data plus lifecycle updates | Must be version-controlled and auditable |
Minimum viable architecture
A compliant architecture is simple in concept: a stable unit ID, a resolvable access path, a controlled data store, and an audit log. The complexity comes from permissions, supplier inputs, and lifecycle updates from multiple actors.
If you cannot answer where the source of truth lives and how history is preserved, you do not have a passport platform.
| Component | What it does | Implementation note |
|---|---|---|
| Identifier service | Allocates and validates unit IDs | Enforce global uniqueness and immutability |
| Resolver endpoint | The URL or service the QR code points to | Keep stable; do not encode environment-specific paths in labels |
| Passport data store | Holds model data, unit data, and update fields | Structured schema; versioned records; evidence links |
| Access control | Controls who can read and who can update | Separate public vs restricted fields; role-based permissions |
| Audit log | Immutable history of changes and access | Append-only event log; timestamped; attributable |
QR code content & encoding strategy
The safest approach is to encode a stable resolver URL that maps to a unit identifier. Avoid embedding business logic or sensitive data inside the QR code. Assume the QR code will be scanned by many parties.
Prefer opaque identifiers. Store meaning in the system, not in the QR code string. If you need to rotate endpoints, do it behind the resolver, not by changing printed labels.
| Option | Pros | Cons |
|---|---|---|
| Resolver URL plus opaque unit ID | Stable, easy to migrate behind resolver | Requires strong resolver uptime and redirect strategy |
| Direct deep link to record location | Fewer hops; simpler debugging | Breaks if hosting or paths change; risky long-term |
| Embedding structured fields in QR | Human-readable and locally decodable | Leaks information; brittle when rules change; hard to version |
Public vs restricted data
Battery Passport data includes both public and restricted fields. A strong implementation separates these layers and enforces access rules consistently.
Decide early which fields are public, which are restricted, and who is allowed to update. Build the separation into the data model and API, not as an afterthought.
| Data class | Typical content | Control requirement |
|---|---|---|
| Public | Required public fields and general model information | Accessible with minimal friction; consistent availability |
| Restricted | Sensitive supply chain, detailed composition, internal quality data | Role-based access; logging; confidentiality controls |
| Update-authorized | Lifecycle event fields updated by service, reuse, or EOL actors | Strong authentication; defined responsibilities; audit log |
Interoperability and data exchange
Battery passports create multi-actor workflows: suppliers provide inputs, manufacturers assemble records, service providers update fields, and recyclers close data. Interoperability is the ability to exchange data without breaking meaning.
At minimum, define field definitions, units, permissible values, versioning rules, and how identity links are maintained across systems. Without this, you get PDF compliance and fragile integrations.
Uptime, continuity & failure handling
If the passport record is inaccessible, you have a compliance failure at the moment of inspection. Treat availability as a compliance requirement, not an IT preference.
Plan for resolver uptime, database resilience, backup restore, and a fallback access mechanism if the primary system is down. Also plan for QR code replacement without changing unit identity.
| Failure scenario | What happens | Control to implement |
|---|---|---|
| Resolver outage | QR scans fail; record inaccessible | High availability, monitoring, and incident response playbook |
| Permissions misconfiguration | Authorized party cannot access required fields | Role tests, regression tests, staged releases |
| Label damage | QR cannot be scanned in field | Replacement workflow; service procedure; linkage to unit ID |
| Data loss | History lost; inability to defend updates | Backups, immutable logs, restore tests |
Audit logging requirements
Audit logs are the core proof mechanism for digital compliance. The audit log should be append-only and capture who changed what, when, why, and what evidence supported the change.
Do not rely on database last-modified timestamps. You need explicit event history for each unit and for each model revision.
| Log field | Why it matters | Minimum expectation |
|---|---|---|
| Actor identity | Attribution and responsibility | User or system identity with role |
| Timestamp | Proves sequence and timing of updates | Immutable timestamp with standard time zone policy |
| Change delta | What changed, field by field | Before/after or explicit delta record |
| Reason or event type | Connects change to lifecycle activity | Controlled list of event types plus notes |
| Evidence link | Defensibility in audits | Immutable links to supporting documents or records |
Quick implementation sequence
Start with a minimal, stable resolver and identity service. Then implement structured data storage and logging. Only then scale supplier intake, permissions, and lifecycle update workflows.
Disclaimer. Informational guidance only. Not legal advice. Validate requirements against official regulation text and implementing acts.