What a Battery Pack Traceability Chain Must Prove to a Buyer-Side Auditor
A battery pack traceability chain passes a buyer-side audit when it can prove four linked facts without anyone rebuilding them by hand: which cell lot went into a given pack, which work order built that pack, which finished serial left the dock, and which shipment that serial went out on. It has to run in both directions — forward from a suspect cell lot to every affected serial, backward from a field failure to the cells inside it — and it has to run inside a response time that already exists in writing before the auditor shows up. If none of that is in the RFQ and the purchase agreement, what gets audited is a favor, and favors expire the moment a program gets busy.
I audit the chain backwards, and I start with a serial I picked myself.
Not a serial from the list the supplier printed for the visit. I pull it off the outbound shipping log, and I look for one built on an ugly day — the Friday before a shutdown, or a week when the line switched cell lots and ran a partial reel through the back half of the shift. Then I write the number on a whiteboard, hand the marker to the quality manager, and start a clock.
The last time I did this, the room was confident for about ten minutes. The manager called production, production pulled the traveler, the traveler pointed to a work order, the work order pointed to receiving, and receiving was a three-ring binder on a shelf in the back. Twenty minutes later a supervisor walked in with a photocopy and said they thought it was one of three lots, but the receiving log for that week had been filled in on the following Monday.
That answer is the answer. Not the apology that came after it.
What a chain looks like when it actually holds
When the thing works, it is boring and it is fast.
The cell can has a lot and date code printed on it by the manufacturer, and that printed code is the only truly immutable thing in the whole system. At receiving, somebody opens the carton and records that printed code against the part number, the quantity, and the receiving date, at the moment the carton is open. That record gets a receiving ID. Kit release to the line draws against that ID. The work order names the receiving IDs it consumed. The build record ties the work order to the cells that went into each module or string. End-of-line test data gets keyed to the finished serial, not to the work order. And the outbound log ties the serial to a PO or shipment.
Four handoffs, four records, each one written by the person who did the thing, at the time they did it.
That last clause is the whole trick, and it is where most programs quietly fail. A receiving log filled out on Monday for a delivery that arrived Thursday is not a traceability record. It is a memory aid. When I find one, I stop asking about documentation systems and start asking who writes what, when, and whether anyone checks it against the carton before the carton goes in the baler.
The anchor, and the two ways people lose it
Everything downstream references the printed code on the cell can. Nothing else in the chain is self-validating. So the entire structure depends on that code being captured while the packaging is still on the floor, because the cartons are gone by the end of the day and nobody is going to reconstruct them.
There are two ways I see that anchor get lost.
The first is a distributor in the middle. Cells bought through distribution often arrive with a distributor's own label on the carton. That label is not the manufacturer's lot code, and a receiving record built from it points to a repack event, not to a cell lot. If you want the manufacturer's code, the purchase documents have to say so, and the receiving procedure has to reconcile both.
The second is the partial reel. A reel gets broken, the remainder goes back on the shelf with a handwritten tag, and three reels of the same part are open at once. If the line pulls by FIFO and a picker grabs the wrong one, no record anywhere will ever show it. That is not a paperwork problem. That is the chain failing at the exact point it is supposed to protect you.
Direction matters more than depth
Most suppliers who claim traceability mean one direction. They can go forward from a work order to the serials that work order produced. That is useful, and it is not enough.
The direction that actually gets tested is the one that comes from the field. A cell lot is called suspect, or a pack fails in service, and now you need the answer to a specific question: which shipped serials contain cells from that lot, and where did those serials go? That question has to be answerable in hours, because your customer is asking, and because every day of delay is a day of possibly shipping more of them.
I test it by asking for a count. If the consumption record says a receiving ID covered a known quantity of cells and a known number of packs, then the forward trace has to return the number of serials that arithmetic implies. When the number comes back short, the gap is the finding. It is almost never a software limitation. It is a shift where the record was made at the end of the day from memory.
Where these chains actually break
Not in the database. At the handoff.
Receiving, when the code gets transcribed from a carton a week later or from a distributor label.
Kit release, when a partial reel moves without a record.
Assembly, when a pack legitimately contains cells from more than one lot and the traceability was specified at pack level. Parallel strings pull from different reels. If your specification says pack-level traceability, you have just described a system that cannot answer the question you are going to ask.
End of line, when the serial number gets assigned after the test and the test data lands on the work order instead.
Outbound, when the shipping log records quantity and model and never the serial range.
Five places. Every program has at least one soft spot, and the audit is not about finding a perfect supplier. It is about knowing which handoff is weak, and whether the supplier knows it too.
Retention is a number you negotiate
ISO 9001 asks an organization to retain documented information needed to demonstrate conformity. It does not tell you five years or ten. That means retention is a contract term, and if it is not in your documents, the supplier's default applies, and their default is usually shorter and often tied to their own quality manual rather than to your fleet's service life.
I tie retention to program life plus the service life of the machines the packs are in, with margin, and I write it as a duration in years from the date of shipment, not from the date of manufacture. I also write down what happens to the records when the supplier discontinues the product line or exits the business, because a retention obligation held by a company that no longer exists is not an obligation.
The PPAP package is a natural place to restate this. Under AIAG conventions, the Part Submission Warrant covers the submission and the supplier commits to retrieving traceability records on request for the life of the program. That sentence is doing a lot of work, and it is worth making the response time explicit rather than letting the phrase on request carry the weight.
Put it in the RFQ or you are auditing a promise
A line item that says the supplier will maintain traceability tells you nothing. What I write into the RFQ is short and specific.
- Granularity: pack serial, module or string, cell lot. Say which level, and say it explicitly for packs that mix lots.
- Data format: a defined field set that can be delivered as structured data, with scanned records as backup rather than as the deliverable.
- Retention: a number, in years, measured from shipment.
- Response time: business hours from the trace request, and who at the supplier owns the clock.
- Evidence: a completed trace on a live program as part of the quote package, not a description of a process.
- Flow-down: the same obligations on any module sub-assembly or sub-tier supplier.
And a clause about what happens at the end, whether the records transfer or get escrowed.
How I run the audit itself
I pick three to five shipped serials myself, spread across build weeks, and I make sure at least one came off a shift with a lot changeover. I ask for backward traces from the serial to the cell lot, forward traces from a lot to serials, and I time both. I ask who touched the record at each step, because a trace that requires three people and two days is a trace that is being assembled, not retrieved. I ask to see the system of record, and then I ask them to trace a serial built before the current quality manager started.
The pilot build is the worst place to judge this. During a first article, everyone is watching, the volumes are tiny, and the chain holds because people care. Test it again at ramp, on the fortieth work order, at the end of a shift.
A small shop with paper travelers and real discipline passes this. A large shop with a shiny MES that only resolves to work order level fails it. The technology is not the variable. Whether the record is contemporaneous and retrievable is.
The reason this is worth the effort is not audit season. It is the night a customer calls and asks whether the packs in their fleet are affected, and you get to look up one number instead of opening an investigation. That number is something you bought months earlier, in the RFQ, when it cost you a paragraph.
