Your RFQ Wording Can Let Suppliers Skip Cell Traceability

Traceability is a bid deliverable, not an assurance. The wording that decides whether you get it is the line requiring every bidder to attach a working traceability file to the quotation itself — an actual spreadsheet from an actual build, with actual lot codes and date codes in it — rather than asking them to describe the traceability process they would follow. One wording gives you a file you can open on the bid tab. The other gives you a paragraph that reads almost identically from every supplier and tells you nothing about whether the data exists at all.

I moved that line to the front of the package, right next to the drawing and the sample requirements, because of what a bid tab looks like without it. Three quotes, three technical responses, all of them saying full traceability is maintained throughout production. You read it, you score it, you move on. Then a field return comes in at month eighteen with a swollen cell and you ask which lot it came from. What comes back is a week of silence and then a scanned certificate covering the cell model — not the lot, not the build, not your pack. The supplier wasn't lying to you. They just never had the file, and nothing in your RFQ ever asked them to prove they could make one.

So sit at the bid tab with me. Three PDFs and three spreadsheets open, and the question on the table is not "does this supplier believe in traceability." It is "does this attachment have columns in it."

Attach the file, don't request the description

When you ask a bidder to describe their traceability process, you get their best prose. Ask them to attach a file and you get a structure: column headers, row counts, a date format, and whether lot codes are populated or blank.

The file does not have to be for your part. It should not be. Nobody is going to hand over another customer's program data, and you should not want them to. Ask for a redacted or sample file from a comparable pack they already build. Redact the customer name, the part number, whatever they need to redact. Leave the field structure intact.

That single request sorts the bid pool faster than anything else in the package. Some bidders send a file within the RFQ window. Some send a template with empty rows and promise to populate it later. Some send three paragraphs explaining why their system is proprietary. All three are legitimate answers, and all three tell you something you cannot get from a process description.

I score it as its own line in bid evaluation rather than a pass/fail afterthought: complete file with populated fields, partial file with gaps, or description only. That ranking tends to line up uncomfortably well with how the first production shipments go.

The minimum field set worth naming

If you don't name the fields, you get whatever their system happens to export, and you'll spend the first article review arguing about a column that should have been settled at bid time. The set I put in writing is short:

• cell manufacturer
• cell model
• lot or batch code
• date code
• quantity consumed from each lot
• pack serial number
• build date

That's the floor. The field that does the most work is quantity consumed from each lot, because it's the one most suppliers can't produce. A file that shows which lots were on the floor during a build is a shift record. A file that shows how many cells from each lot went into this specific pack serial is a build record, and only one of those answers an investigation question later.

Watch for a trap here: a file where the pack serial column is a range, like 4001–4120 on a single row. That's not traceability to the unit. It's traceability to a work order, and it collapses the moment you need to know whether two returns came from the same build.

Format and timing belong in the requirement

Say what you want delivered and when. "Traceability documentation available upon request" is the phrase that kills you, because available upon request means a person opens a folder and assembles something, and that person is busy.

What I specify now: a spreadsheet, delivered per shipment, alongside the packing list, with defined column headers. Not a scanned certificate pulled at request. Not a PDF that someone types up after you ask.

There's a real tradeoff in that. A scanned paper traveler from a small shop can be perfectly good evidence — legible, complete, signed at each stage. I've accepted photographed travelers before. The point isn't the file format. It's whether the data already exists as a byproduct of the build or has to be reconstructed when someone asks for it. Reconstructed data is the expensive kind, and it's the kind that arrives wrong.

Also decide how you'll keep it. If every shipment lands as a separate attachment in someone's inbox, you don't have a traceability system either. Have a named folder structure or a shared drive location in mind before you ask for the first file.

The retention question almost nobody asks at bid time

Retention is where traceability quietly evaporates. If a supplier's records policy deletes build files at the end of the warranty period, and your investigation starts in year three of a five-year warranty, the file is gone before you needed it.

So ask two things, not one. How long do you keep build records. And how fast can you pull the record for one pack serial if I send you the number on a Monday morning.

The second question is the honest one. I care less about a retention policy than about retrieval time, because a policy with no retrieval path is a promise. Anything measured in days is workable. Anything that turns into "we'll have to check with the plant" is a signal about where the data actually lives.

Lot mixing is where the story usually breaks

Ask each bidder, directly, whether a single build can contain cells from more than one lot. Most will say yes, because cells are consumed in order and a lot runs out mid-run. That's normal manufacturing, and it isn't a defect.

What matters is whether the file records the split. If a pack contains cells from two lots, the quantity-per-lot columns should show it, not average it away. If a bidder tells you one lot per build, ask what happens when the lot runs out halfway through a shift — and listen to whether the answer describes a process or improvises one.

This is also the moment to ask how partial lots are handled at changeover, and whether the partial reel or tray is labeled with its lot code at the line. If the label follows the material, the record can follow the pack. If it doesn't, no amount of software fixes it.

Change notification and the re-qualification path

Cell source, cell model, and manufacturing plant are the three changes that invalidate your traceability assumptions. Ask bidders to notify you in writing before any of the three changes, and ask them to describe the re-qualification path they'd follow — what sample they'd submit, what internal testing runs, how long approval takes.

Defining that path at bid time costs you nothing and saves a negotiation during a production ramp. A supplier who can't describe how they'd re-qualify a new cell source is a supplier who has never had a customer ask. Which is exactly the information you were fishing for.

Your counsel reviews the wording and decides what is enforceable. I'm describing what to ask for and what to look at, not drafting clause text.

Tie the file to a milestone

A traceability deliverable that arrives whenever the supplier gets around to it is a courtesy, not a condition. Attach it to something with a date on it. First article approval is the natural gate: approval isn't granted until the file for the first article build is delivered and accepted. A payment tranche is the other lever.

This isn't about punishing anyone. It's about putting the deliverable on the same calendar as everything else in the program, so it competes for attention with the things that already have deadlines.

What the file actually tells you when you read it

A few tells I've learned to look for in the sample file itself:

Lot codes present but date codes blank. The lot code came from the cell label; the date code has to come from a different record, and nobody reconciled the two.

A quantity column that sums to a suspiciously round number across a hundred packs. That's an allocation, not a count.

Column headers that describe intent rather than data — "Traceability Info" as a single free-text column is not a field set, it's a comment box.

A file that exists for the finished pack but has no relationship to the incoming inspection record for the cells. Two half-records that were never joined.

None of these are disqualifying on their own. Together they tell you how much work stands between this supplier and a file you could hand to an investigator.

Keep it small enough to stay true

One caution against over-asking: every extra column you demand is a column that gets filled in wrong under volume. I've seen field sets grow past twenty fields and watched the data quality fall as the engineers filling them in started guessing. Name the fields you will actually use in a failure investigation, and stop.

And spot-check. Once a quarter, pull three pack serials from shipments already received and ask for the records by a stated deadline. That single habit tells you more about whether the process is real than the sample file at bid time ever could, because it tests the supplier when nobody is watching.