Three UN 38.3 Tests Destroy Your Samples, So Plan Your RFQ

Three of the eight UN 38.3 tests — impact, overcharge, and forced discharge — leave the unit unusable, so the sample count in your RFQ has to be built backward from the test matrix instead of copied from whatever kit the supplier usually ships. Put that count in the RFQ as its own line item tied to a build source: production line, production documentation, production fixture. Split the schedule into sample build time and laboratory queue time, because only one of those belongs to your supplier. And match every test summary in the quote against the exact build being offered, since a report issued for a prototype does not travel with a production pack.

The lab I use has a steel shelf behind the intake counter. A technician walked me down it once, while a pack sat on the bench waiting for its intake photographs. Bottom row, a battery with the corner crushed in and the case split along the seam. Middle row, one that had vented, cell wrapper curled and brown. Top row, a unit where a cell had been driven into reverse polarity until it quit. Three rows, three tests, three pieces of hardware that were never going to be anything else again.

That shelf is the arithmetic nobody puts in the quote.

Eight tests do not mean eight packs

UN 38.3 has eight elements. Altitude, thermal cycling, vibration, shock, and external short circuit are usually sequenced onto a single pack — one unit walks through the whole run and comes out the other side, more or less. Then impact takes a pack, overcharge takes a pack, forced discharge takes a pack. So the floor is four units, not eight, and if you walk into an RFQ assuming one-for-one you'll over-order. If you assume the supplier will "provide samples as needed," you'll under-order, and you'll find out in month four.

I don't trust the four-unit floor either. A short-circuit run can leave a pack I wouldn't want to put back on the vibration table, depending on how the protection behaved, so I plan for a spare. And repeats happen. The first overcharge run tells you something you didn't want to know, and now you need a confirmation on identical hardware, and identical hardware means another build cycle unless you already bought the unit.

Cells are their own line. A cell-level program consumes cells — they don't come out of the pack program, and they don't come back. I count packs and cells separately in the RFQ and label them separately, because the moment they're one lump sum, the supplier builds whichever is cheaper to build.

The number I won't give you

I'm not going to hand you a sample quantity, because the right number falls out of things only you know: how many configurations you're quoting, whether your lab wants a witness unit on the shelf, whether you can tolerate a repeat costing you a full build cycle, whether the pack is going into a pilot fleet that has to keep moving while the lab works.

What I will give you is the shape of the answer. Start with the test matrix. Mark the destructive elements. Add one spare per destructive element if your schedule can't absorb a repeat. Add cells for the cell program. Add one more pack if your contract manufacturer's build yield on a first article is an unknown, which on a new pack it usually is. That's your number, and it should appear in the RFQ as a quantity, not as a sentence about cooperation.

Build source is the part people leave blank

"Samples" is not a specification. I've watched a supplier deliver beautiful hand-built units out of an engineering lab — machined housing, hand-loomed harness, a BMS on a bench fixture — and the test program ran clean, and the production pack eighteen months later didn't resemble any of it. Not because anyone lied. Because nobody wrote down where the samples had to come from.

So the RFQ says: production line, production documentation, production fixture. And I mean it as a check, not a formality. When a supplier builds a sample to the production drawing set, the build is the first real read on whether those drawings are complete. I've sat in a sample build review where the assembler asked what torque the busbar fasteners took, and the drawing didn't say, and the room went quiet — which is exactly what you want to happen in month one instead of in a work instruction review two weeks before launch. The sample build is a documentation audit that you get for the price of the samples.

Two dates, not one

The single most common thing I have to send back on a battery RFQ is a schedule with one line on it. "Samples and testing: twelve weeks." Useless. I can't tell from that whether the supplier is slow or the lab is backed up, and neither can they, and by the time it slips neither of us can prove which one moved.

I ask for three dates: sample build complete, laboratory test start, test report issued. The first belongs to the supplier. The second belongs to the lab queue, which is outside the supplier's control and outside yours, and pretending otherwise is how schedules get signed that nobody can meet. The third depends on whether anything fails and has to be re-run, so I treat it as a range and I say so.

There's a circularity in here that catches first-timers: the samples have to reach the lab before the pack has a test summary, and shipping lithium packs without a summary is its own conversation with your freight forwarder and your dangerous goods provider. I raise it in the RFQ rather than at the dock, because the answer affects how the samples are configured for transport and who books the freight.

That summary in the appendix isn't yours

Almost every quote comes with a UN 38.3 test summary attached. Almost none of them cover the thing you're buying.

The summary is valid for the configuration that was tested. Change the cell, and it's not your pack anymore. Change the BMS, the protection circuit, the housing, the firmware that governs the cutoff, and it isn't either. Suppliers aren't being slippery about this — they have a summary from a program that looks a lot like yours, and they'd like you to have it, and it will get you through a surprising number of conversations before someone downstream asks a question it can't answer.

So the RFQ asks for a configuration statement, one page, signed, listing what was tested: cell manufacturer and part number, cell date code range, pack part number and revision, BMS hardware revision, firmware version, and who built it. Then I put the offered configuration next to it and read across. If the answer comes back "same design," I ask same as what, and I keep asking until there's a part number on the page.

I also ask what triggers a retest on their side and who notifies whom when a cell gets discontinued or a BMS gets a firmware revision. That clause has saved me once, on a program where the cell changed between the sample build and the first production run, and the summary on file had been issued for hardware that no longer existed.

What goes in as line items

Samples, in two quantities, cells and packs, each with a build source written next to it. The three schedule dates, in three rows. The configuration statement as a deliverable with a due date, not an attachment. A disposition instruction for the tested units — retained by the lab, photographed, returned or scrapped — because the failed units are the most informative hardware in the whole program and I want them documented before they go in a bin. And the change-notification clause, with the requalification trigger spelled out.

None of that is exotic. It's just the difference between an RFQ that asks for a battery and an RFQ that asks for evidence.

The day it matters is the day the pilot build is ready and the lab slot is still weeks out, and someone asks you why the schedule has a hole in it. If the samples were counted, sourced, and dated on the front end, the hole is somewhere you can point at.