What a Battery Pack Supply Agreement Should Say About Lot Records

Lot records have to be written into a battery pack supply agreement as a deliverable, with four operating variables attached to them: a retention period, a file format, an audit right, and a trace-request response time. Take those four out and everything left in the document about traceability, the quality clause, the ISO certificate stapled to the appendix, the sentence about full lot control, is decoration. It reads well, it means well, and on the morning you actually need an answer it produces nothing you can act on.

I learned that over eleven days, and the eleven days are the reason I now argue about record language before I argue about anything else in the pack.

The pack vented at 7:40 on a Tuesday, mid shift change, on an AMR that had been running the same three aisles for about three years. Nobody got hurt. The unit stopped sideways in the aisle with a pallet still on it, and the smell got to the break room before the alarm got to my phone. By 9:00 I was standing next to the unit with a photo of the pack label on my screen. Silver sticker wrapped around the case, part number, an eleven-character serial, and a date code I had looked at a hundred times without ever needing to read it.

By 9:15 I needed to read it, because the question from operations was not what happened to unit 34. It was how many other units out there have cells from the same lot. Sit with that question for a second, because it's a completely different animal. It isn't an engineering question. It's a records question, and it has a deadline attached to it that nobody in the room controls.

I sent the serial to the supplier that morning. The replies came back like this, and I'm giving you the real sequence because the sequence is the point.

Day four, a summary spreadsheet keyed to production week. Useful for a slide. Useless for a containment decision, because production week doesn't tell me which of my units to go touch.

Day six, a correction. The lot identifier in the first file wasn't the cell lot number. Somebody had sent me their internal build batch instead. This is not dishonesty. This is a supplier answering the question they thought I asked, using the only field they had in front of them.

Day nine, a phone photo of a paper traveler card. I could read it. I could not join it to anything.

Day eleven, a PDF. That's when I had an intern retyping sixty serials into a spreadsheet, and that's when I started counting what the eleven days had actually cost: a fleet inspection I didn't need, two days of an operations supervisor's time, and a conversation with our own quality lead where I could not answer a direct question about scoped exposure.

The agreement we had actually said the supplier would maintain full traceability of all lots. Nine words. No retention period. No format. No clock. No right to go look. Nine words, and a promise that had never once been operated against by anybody, on either side, until the morning it mattered.

I don't treat that sentence as the finish line anymore. I treat it as the starting gun.

Retention is the only promise you can put a date on

A retention period of "as long as required" is not a period. What I ask for is measured in years, expressed as the warranty term plus a defined tail, and I want to know exactly when the clock starts.

Start dates matter more than people expect. Pack ship date is the easiest to prove, because it's on a packing list. Pack build date is more meaningful, because it's when the cells went in. Cell manufacture date is the one that actually matters in a field failure, and it can sit months behind the build date if the packs sat in an integrator's warehouse before they ever hit my floor. If I don't pin the start date, I get the one that's most convenient to the supplier, and I won't find out which one that is until I'm asking.

Two things I've added after getting burned. First, the obligation has to survive the end of the supply agreement itself, not just the warranty term, because field failures on a fleet that's been in service for years don't respect a contract expiration date. Second, on programs where the supplier isn't obviously going to be around in five years, I've asked for the records to be delivered to us on termination for every pack shipped in the preceding period. You can't send a trace request to a company that no longer exists. I'm describing what the clause needs to accomplish, not drafting it. The actual language goes to counsel.

Format decides whether the record joins to your fleet list

This is the part that gets skipped, and it's the part that decides whether you can answer the question in an hour or in eleven days.

What I want is a flat file, one row per pack, that joins to our own asset list on the pack serial. Practically, that means CSV or XLSX in an agreed schema: pack serial, cell manufacturer, cell part number, cell lot code, cell date code, module lot, pack build date, ship date, BMS firmware version at build, and a pointer to where the test records for that lot live. Per shipment, or on request, whichever we've agreed.

What I do not want is a PDF. A PDF is a picture of a record. A phone photo of a traveler card is a picture of a picture. Neither one joins.

One detail that sounds fussy and isn't: the serial string in the file has to match the string printed on the pack label character for character. Same hyphens, same leading zeros, same case. I've spent an afternoon reconciling two lists that were the same list, because one system stripped a leading zero and the label didn't. Fix the string format in the schedule and you never have that afternoon.

And a second, less obvious use: a per-serial file tells you something about the supplier's process control before you find out the hard way. A pack house that can produce one is running a real traveler system. A pack house that can't, and tells you so plainly, has just told you something honest and useful about how their line is run.

Raw records, summaries, and the right to look

Data rights language usually gets written for the wrong problem. This isn't about who owns what intellectually. It's about whether you receive the underlying records or a summary that somebody selected for you.

There's a difference between a lot summary and a lot index, and I've had both handed to me with the same cheerful email. The summary is aggregated to a level that makes someone's quality report look clean. The index is the list of which specific packs got which specific cells. I want the index by default, and I want the right to demand the underlying traveler and test records behind it.

Which leads to the audit right, because a right to demand something is worth very little if the only enforcement mechanism is another email that doesn't get answered. Audit rights let me verify records on site. The scope points I care about: notice period, how often, whether the scope is limited to records tied to my part numbers, and whether I can bring a third party. Limiting scope to my part numbers is not me being generous. It's how the clause actually gets agreed to.

The one that surprises buyers is the sub-tier question. Most pack suppliers are assemblers. The lot code I care about most belongs to the cell maker, and the pack house may not have the standing to pass it through to me. That is a commercial problem to solve at contracting time, not a records problem to solve during a failure. Either they can re-disclose it, or they can't, and I'd rather know in the negotiation than in the containment meeting.

A trace request needs a clock on it

Here's the sentence I now insist on, in substance: a trace request gets an acknowledgment inside a defined number of business days, a preliminary lot scope inside a second defined number, and complete records inside a third. Split into three, not one, because the first answer is what stops the bleeding and the complete file is what closes the loop.

Without a clock, the process is we'll look into it. With a clock, somebody at the supplier has a task with a due date, and their manager knows it exists. That's the whole trick. A supplier will staff against a number. It will not staff against a virtue.

Three supporting details make the clock usable. Name the channel and the contact by role, plus a named backup, so a request doesn't die in a shared inbox. Define the trigger events that put the clock in motion, because any field failure, any thermal event, and any customer escalation are the ones I care about. And define the request format from my side, so that what I send is a serial list they can drop straight into a query instead of an email they have to interpret at 4:30 on a Friday.

Where the four belong, and what not to fight about

All of this lives in the commercial instrument, not in the technical specification. The performance requirements tell you what the pack has to do. The records clause decides whether you can ever prove what it did, and it has no teeth at all if it's sitting in an appendix nobody reads.

Structurally, I keep it to one records-and-audit clause that references a schedule, and the schedule holds the column schema, the cadence, the response times, and the retention tail. Schedules are easier to update than clauses, and schemas change more often than contract language does.

Cover the pilot with the same terms. That's not a formality, it's a test, and I'll get to it in a second.

What I let go: format sophistication. JSON versus CSV is an argument about nothing. Real-time portal access is a nice-to-have that I'll trade. A quarterly reconciliation for a low-volume program is fine. A small assembler with no exportable MES is a real constraint, and asking them to build an API is asking them to build a product.

What I don't let go: the retention tail, the response clock, the per-serial join key, and the audit right. Those four are the difference between owning the information and renting access to a summary.

Test it during the pilot, before it matters

The cheapest thing I do on any pack program now is this: after the first pilot lot ships, I send a trace request for two or three serials from that lot and time the response. Not a real failure. A drill. It costs the supplier an hour and it tells me whether the clause I negotiated exists as a capability or as a paragraph.

I've had the drill come back in a day and a half with a joined file, and I've had it disappear for a week. Both answers were worth having early, while there was still something I could do about them, and neither one required a fire to find out.

The thing I'd want you to take out of the Tuesday morning I described is that I wasn't short on traceability. The supplier was tracing everything. Their records were fine. What I didn't have was a way to reach those records on a schedule, in a shape I could use, from a company that was contractually on the hook to give them to me. The record was never the deliverable. Access to the record was, and access is a commercial term, which means it's negotiable, and it means if you don't write it down, you don't have it.