A cell swap can quietly invalidate your pack certification

A cell swap invalidates pack certification when it pushes the shipped configuration outside the configuration that was actually tested, and the only dependable way to catch that is to re-read the existing test evidence against the change before the change is approved. Same 21700 format, same nominal capacity, same chemistry family — none of that settles the question. Two documents settle it: the configuration description inside the test report, and the critical component list attached to the certificate. If the new cell is not the cell those documents name, the evidence on file describes a pack you are no longer building.

I have sat on both sides of that sentence. Approving the change on one side, and on the other side standing in a forwarder's office with a test summary in my hand, trying to explain why the pack on the pallet and the pack in the report were close but not identical. The second one stays with me longer. So now I read change notices the way I read invoices — looking for the line that doesn't belong.

The change notice that started this

Three pages. Page one is a cover sheet with a tracking number. Page two is a table of affected part numbers. Page three has a field labeled "Reason for change," and the field says "supply continuity."

The engineer who forwarded it wrote three words above the attachment: form, fit, function identical.

That phrase is where I slow down. Form, fit, and function is a manufacturing judgment, and a fair one — the pack will assemble, mount, and run exactly as before. But certification was never a test of form, fit, and function. Certification is a test of a named configuration, and configuration is a much longer list than fit. It includes which cell, which BMS board revision, which firmware build, which enclosure resin and wall thickness, which interconnect gauge and routing. The pack can be indistinguishable in the hand and still be a different tested article.

So I open the test report to the page that describes the sample. Not the summary page with the pass column. The page where the lab wrote down what it received.

What the certificate actually names

A pack certificate is not a stamp applied to a product line. It is a photograph of one build, taken on one date, with the build's parts listed beside it. The critical component list on a CB certificate, or the construction description in a UL follow-up document, is that list. Cell model appears on it. So does the protection circuit. That list is the thing that gets audited at the factory, and it is the thing a customs broker or a carrier may ask you to reconcile against a shipment.

That is the part people miss. The certificate does not go stale because time passes. It goes stale because the build moves and the photograph doesn't. A certification I approved eighteen months ago is still perfectly valid evidence — for the pack I approved eighteen months ago. Whether it is valid evidence for what ships this quarter is a separate question, and it is my question to answer, not the lab's.

Seen that way, a certification is a decaying asset. It starts decaying the moment the first unreviewed change lands, and it decays quietly, because nothing about a small change announces itself.

The cell

Cell model is the one I check first, because it is the one most often waved through. A second source qualified for supply continuity, same format, same capacity, same chemistry family, datasheet curves that overlay almost exactly. Commercially it makes complete sense.

Technically, that substitution changes the tested configuration. The cell is inside the sample that went through altitude, thermal cycling, vibration, shock, external short circuit, impact, overcharge, and forced discharge. Every one of those outcomes belongs to the cell-plus-pack assembly, not to the pack shell. A different cell means the recorded outcomes were produced by hardware that is no longer the hardware.

Sometimes the answer is genuinely that the existing evidence still carries it. The certificate schemes anticipate this — family or representative-model approvals exist precisely so that variants can ride on one test program. But that argument only works if the manufacturer can document why the new cell stays inside the family: it has to line up against the parameters the family was defined on, and that reasoning has to sit in a file, not in someone's recollection from a phone call.

The firmware revision nobody flags

Here is the one that gets past experienced buyers. A firmware revision arrives with no hardware change at all. No new part number on the pack label, no ECO against the bill of materials, nothing to physically inspect. It reads like software maintenance.

But firmware owns the protection thresholds and the charge profile. Protection thresholds are exactly what the overcharge and external short circuit tests interrogate — the test drives the pack into a fault, and the pack's response is decided by the limits coded into the board. Move the cutoff, move the timer, move the current threshold, and the pack's behavior under fault is no longer the behavior that was recorded.

So I want the firmware release record, and I want the change description in it, not just the version number. If the release notes say the revision touches thresholds or charge profile, that is an engineering review of the existing evidence, full stop, before the revision goes into production. If the release notes say it is a display fix or a communications tweak, I still want the note in the file — because the note is what lets me prove later which build was running when.

Enclosure, mounting, interconnects

These are the mechanical ones, and they are easier to reason about because you can see them. Vibration, impact, and crush outcomes depend on mass distribution, mounting geometry, and how the assembly is held together. Change the enclosure resin, change a mounting boss, change the interconnect gauge or route a cable differently, and the mechanical results belong to a different physical object.

I do not treat "small mechanical change" as a category. I treat it as a question: does this change touch anything the mechanical tests were measuring? A label change doesn't. A mounting point does.

The three questions I ask before I sign

I keep this short on purpose, because a long checklist gets skipped and a short one gets used.

First — does the change touch a critical component, a tested parameter, or a protection threshold? If no, the file gets a note and I move on. Not every change is a requalification, and pretending otherwise buries the ones that matter.

Second — does the existing evidence describe the new configuration in its own words? Not "close enough." I open the report and read the configuration section against the change. If the report names a cell, a board revision, and an enclosure, and one of those three just moved, the report is describing the old build and I know where I stand.

Third — will I be able to prove, two years from now, which build shipped in which month? That is a documentation question, and it is the one that saves you. Change notes, engineering change orders, firmware release records with dates and descriptions. Not because a regulator will read them, but because when a customer asks, or a forwarder asks, or an auditor walks the line, the answer has to come out of a file rather than out of a meeting I half remember.

Dual sourcing, handled deliberately

Dual sourcing is normal and often necessary. The mistake is treating the second source as interchangeable by default and reviewing it only if something goes wrong.

What I do instead: each source gets mapped against the certified configuration, one at a time, in writing. If the second source rides on the existing approval, the file says so and says why. If it doesn't, the review happens before the first production lot, not after. The cost of that mapping is a few hours. The cost of discovering it during a shipment is a different order of problem.

And when a change is approved on the strength of existing evidence, I write down the reasoning in the same file. The reasoning is the asset. Six months later, the person who made the call may be at a different company, and the file has to stand on its own.

What I'd want you to take from this

The shift is small but it changes how you read every change notice that crosses your desk: certification is not a milestone you clear, it is a state you maintain. Once you accept that, an ECO stops looking like paperwork and starts looking like a decision about whether the evidence still applies. Most of the time the answer is yes, and you write a line in the file and move on. Occasionally the answer is not yet, and that is the whole reason the review exists — not to slow the change down, but to make sure the day someone asks you to prove what you shipped, you can.