Silent Cell or Firmware Changes That Undo Your Pack Qualification
A change-notification clause only has teeth when three things are nailed down before the first production order: the specific changes that must trigger notice, a supplier change control procedure that actually produces a customer-facing notification, and the requalification steps the buyer runs when the notice lands. Missing any one of those three, a pack that passed qualification last quarter can ship this quarter with a different cell, a different weld schedule, or a different firmware build, and nothing in the receiving paperwork will show it.
Stand at the receiving bench with me. Same carton. Same part number on the pack label, same revision letter, same barcode I scan into the incoming log. What is different is inside the shrink wrap. The date code on the cell cans is printed in a format I have not seen from this line before, and the nickel strip running across the busbar is a hair narrower than the strip on the golden sample sitting on the shelf behind me. My inbox is quiet.
Nobody lied to me. The supplier ran an engineering change, closed it out in their own system, revised their internal drawing, and shipped. That is what an internal ECO is designed to do. It is not the same function as telling the customer, and the two get confused constantly.
I keep a caliper and a USB-CAN adapter at that bench for a reason. The caliper catches the strip. The CAN adapter catches the firmware string, and the firmware string is where the quiet changes live.
What has to ring the bell
The trigger list is the clause. Everything else is administration. On a custom pack, I want these named explicitly, not summarized as "significant changes."
Cells, BMS, and anything below the first tier
Cell supplier, cell part number, and any change to the cell's internal construction, even when the model number stays identical. Electrode formulation, separator, electrolyte additive package, tab configuration, can geometry, vent design. Manufacturing site or production line transfer for the cell itself.
BMS hardware: bare board supplier, PCB revision, protection IC, MOSFET, shunt, fuel gauge, thermistor part number, layout change that moves a sense trace.
BMS firmware: any binary revision, and any change to a configuration or parameter table, which is the one people argue about. A threshold moved by one degree is a different pack. A balancing current changed by twenty milliamps is a different pack. If the config file is flashed separately from the application image, it still counts.
Any sub-supplier substitution anywhere on the bill of materials, including the ones the pack house does not buy directly. That last phrase is where most trigger lists fall apart.
Process and material changes that leave no fingerprint on the label
Welding process is the big one. Ultrasonic to laser, a changed weld schedule, new horn or anvil tooling, a different tip geometry, or a reduction in the number of welds per tab. None of it changes the outside of the pack. All of it changes the joint.
Housing material grade or resin supplier. Wall thickness. A move from machined to molded, or a new mold cavity. Connector and terminal source, plating thickness, crimp tooling. Potting compound, conformal coat, adhesive, or thermal interface material substitution. Test equipment replacement, or a new end-of-line tester that computes the same value a slightly different way.
I ask for the trigger list as an appendix, one page, terse, with the part numbers and process steps named. A trigger list that needs interpretation is a trigger list that gets skipped.
The procedure behind the promise
A supplier's documented change control procedure is the thing I actually audit, because the clause in the quality agreement is only a promise. The procedure is the machinery that keeps it.
What I want to see in it:
A named owner, and a classification scheme with written criteria rather than a judgment call made in a meeting. Major, minor, critical with definitions tied to safety, form-fit-function, and regulatory marking.
The trigger list itself, referenced, not paraphrased.
A timeline: how many days before the first shipment of changed product the notice goes out, and what the urgent path looks like when a line is down and the supplier genuinely cannot wait. Deviations and waivers are fine. Silent shipments are not.
A standard notice form with fixed fields. What changed. Why. Which part numbers, which date-code ranges, which first affected lot. Before-and-after test data. A risk assessment. Whether the supplier proposes requalification and what samples they can provide.
An acknowledgment loop. I want it written that silence is not approval. Nothing should ship on a changed configuration until somebody on my side signs it, or until the stated notice period expires, whichever the program has agreed to.
Records retention, traceable to shipment. The notification, my response, and the firmware revision for each lot, held long enough to be useful if a field issue shows up two years out.
The omissions I find most often: the procedure covers new product introduction but never running changes. The trigger list exists internally but the customer-facing notice is generated by a sales coordinator with no deadline attached. The procedure has no firmware field at all. There is no provision for the supplier's own sub-suppliers. Nothing ties the drawing revision to the notice, so drawings change quietly and the pack label follows a week later.
Internal ECO is not a customer notification
This distinction is worth more than the rest of the clause combined.
An ECO exists to control the supplier's own build. Its purpose is internal consistency and traceability. It works well. When a process engineer changes a weld schedule, the ECO routes for approval, the drawing updates, the work instruction updates, and the shop floor starts building the new version. That system is doing exactly what it was built to do.
A product change notification exists to move information outward. It only happens if a specific person owns it and a specific deadline drives it. In most suppliers I have audited, that person is not the process engineer who raised the ECO, and the ECO system does not push anything to a customer.
So I sit in the conference room and ask for two logs, covering the same twelve months, for my part number. The ECO log and the notification log. Then I lay them side by side. Every line in the first log with no matching line in the second is a finding, and I do not need to argue about intent, because the paper already did it. I have found weld schedule changes, a connector source change, and a cell date-code origin shift this way, none of which were classified internally as anything but a routine process improvement.
That is the honest failure mode. It is rarely concealment. It is a classification decision made by someone who does not know which characteristics I qualified against.
Firmware belongs in document control
A pack's firmware is documented information that happens to execute. Treat it that way.
I require a readable revision string on every pack, either over the CAN interface or from a test pad, and a per-shipment revision log tying date-code range to firmware revision and a checksum or hash. Not the marketing version number. The actual build identifier, plus the effective configuration.
I also ask who can commit to the firmware repository, whether the parameter tables live under the same version control as the code, and whether there is a build record that ties a given binary to a given source revision. Suppliers who are rigorous about this answer in about four minutes. Suppliers who are not answer in circles, and that tells me how the next year is going to go.
The reason this matters more than any other single item: firmware changes leave no physical trace. A cell change eventually shows up in a date code or a weld appearance. A firmware revision shows up nowhere unless you go looking for it, and a threshold change can affect when a pack shuts down under load, which is a safety behavior, not a feature.
What I requalify after the notice lands
Not every notified change deserves the same response, and pretending otherwise burns money and schedule. The test I use: did this change touch a characteristic that appeared as an acceptance criterion in the original qualification report? If yes, it gets tested again. If no, it gets a drawing update and a note in the file.
When it does touch one, the sequence is consistent.
First article inspection against the revised drawing, with the revision level visible on the pack label and in my receiving checklist, so the new configuration is detectable at the dock.
A sample build from the first production lot after the change. If only a hand-built sample is available, I take it, and I mark the qualification as provisional until a production lot is verified. I have been handed a beautifully built sample that bore no resemblance to what came off the line, and I do not want to learn that lesson twice.
End-of-line test data comparison. Same test profile on the new lot and on the last qualified lot, compared as distributions, not as pass or fail. Capacity, DC internal resistance, self-discharge, hi-pot, weld pull strength, weight. A shift that stays inside the spec limits is still a shift, and I want to know it exists before it drifts out.
Functional verification of the safety behaviors if the change touches the BMS or the cell: overvoltage, undervoltage, overcurrent, over-temperature, balancing, and communication with the host device.
A targeted reliability subset. Cell or weld change, the abuse and thermal subset goes back through. Connector change, contact resistance and mating cycles. Housing change, drop and ingress.
Documentation refresh: drawing revision, bill of materials revision, control plan, inspection criteria, label revision, and my own qualification record. The pack's internal master part number should reflect that a new configuration exists, or purchasing and receiving will be working from two different truths.
Putting the expectation in the quality agreement
I write the change-notification section as a list of expectations and hand it to counsel. I do not draft binding language myself, I do not take a position on liability, and I do not write remedies. Those are legal questions with legal answers, and the value I add is knowing precisely what the operation needs to be told and when.
The purpose of the clause, described plainly: the supplier tells the buyer about changes to the qualified configuration, in a defined form, within a defined window, before the changed product ships, and the buyer has a defined opportunity to respond.
What I hand over as expectations: the trigger list as an appendix, the supplier's change control procedure attached as an exhibit rather than summarized, the notice period, the required fields of the notice, the statement that shipment does not precede acknowledgment, the firmware revision log requirement, the right to review the change log during an audit, and the requirement that the same obligations flow to sub-suppliers.
Then I keep a copy at my desk and I actually use it. A clause nobody reads during a routine lot is just a page in a binder.
The point of all of it
The qualification report I paid for covers one configuration. One cell, one weld schedule, one firmware build, one housing, one connector, at one set of sites. That is the asset. Change notification is the mechanism that keeps the configuration I qualified and the configuration arriving at my dock the same thing, and the trigger list, the procedure, and the requalification plan are what turn a clause into a working control.
When the next carton arrives with a date-code format I do not recognize, I want to already know why.
