The certificate-filing habit that quietly fails after your first pack change
The certificate-filing habit that quietly fails after the first pack change is filing by document type instead of by pack revision. A folder of PDFs named for the test or the certificate number works fine while the pack has only one revision, then stops working the moment an engineering change bumps that pack to a new revision, because nothing in the folder says which document belongs to which build. The fix is to run the compliance evidence set as a controlled document system: test reports, certificates or listings, declarations of conformity, and the drawing or BOM revision each was issued against, every one of them versioned, named to a fixed convention, indexed to the pack revision it covers, and retained for as long as the customer contract or the end product's regulatory regime requires. Done properly, an audit request is a lookup. Done the way most teams do it, the same request is an afternoon of archaeology.
It's a Tuesday morning and I'm sharing my screen with a customer's quality auditor. She wants the safety listing that covers the packs we shipped in March, plus the listing it replaced. I open the compliance folder for that program.
Fourteen PDFs. Two of them are named certfinal.pdf and certfinal_updated.pdf.
Both are valid. Both came from the same lab, both cover the same product family, neither one has been altered. And neither one tells me which of them is right for the March build, because the certificate carries the holder's legal name and the model designation assigned by the lab, and those two fields are not mine to edit. The one field I actually needed, the pack revision, was never written on either document. It only exists in the drawing package and in the build record, which is a different system on a different screen.
So there are three windows open for one question. I get the answer in about ten minutes because I happen to know which change order landed in March. The auditor says thank you. Her next question is about a program I inherited from someone who left, and that one takes a day and a half.
Nothing was wrong with the compliance. Everything was wrong with the filing.
Four document types, and one that isn't really a document
A working compliance evidence set for a custom pack holds four things:
- Test reports, including the transport test summary and the cell and pack level safety testing.
- Certificates or listings issued against the pack or against the cells inside it.
- Declarations of conformity, where the destination market requires one.
- The drawing or BOM revision each of the above was issued against.
The fourth item is the one people drop, because it isn't a compliance artifact at all. It's a manufacturing artifact. But it is the only thing that anchors the other three to something real. Without it you have three documents that prove something about a product, and no way to say which product.
The pack revision is the spine
Everything on a certificate is fixed at issue. The certificate holder is a specific legal entity. The model designation is a specific string the lab assigned. A buyer cannot add a revision letter to someone else's certificate, and shouldn't want to.
What a buyer controls is the linkage. If the linkage isn't recorded somewhere the buyer owns, the document is unattached, and an unattached document becomes unusable the first time the design changes. That's the whole failure mode. It isn't that the certificate expired or that the product failed. It's that at some point a document stopped being connected to a build.
The linkage lives in three places, and they should all say the same thing: the file name, the index, and the folder path. If those three disagree, assume an auditor will find the disagreement before you do.
Naming, briefly
Pick a convention and never make an exception, including on a Friday. Something shaped like familyrevisiondoctypeholderYYYYMMDD. Use the revision identifier that's already on the drawing. If engineering calls it Rev C, the file says Rev C. Do not renumber into your own system, because then two numbering systems exist and someone will eventually cross them.
The words to ban outright: final, updated, latest, new, revised. Every one of those is a lie on the day it is typed, and none of them sorts into a timeline.
The index is the whole thing
One sheet. One row per document. Pack revision, document type, document identifier, holder, model designation, issue date, expiry or renewal date if there is one, superseded by, and where the file lives. That's the artifact that answers an auditor's question without opening anything.
I've seen it as a printed page in a binder and as a shared spreadsheet. Both work. The habit is the point, not the tool. Update it the same day the document reaches your desk, because a document that arrives and isn't indexed is a document that will be lost inside a folder of fourteen near-identical PDFs.
The superseded-by column is the one people skip. Keep it, because it's how the previous versions stay visible instead of drifting away.
Supersede, don't overwrite
Auditors routinely ask for the old document as well as the current one. They aren't being difficult. They're checking that the change was controlled: that you knew what you were shipping before, that you knew what changed, and that nothing happened in between that nobody noticed.
Overwrite the old file and you've created a gap that no amount of explanation fills, because the explanation is coming from memory and the document that would prove it is gone. The rule is simple. Nothing gets deleted, nothing gets overwritten. The old file gets marked superseded, with the date, and stays reachable through the index.
Retention is set somewhere else
How long you keep the evidence is not a decision the sourcing team gets to make. It comes from the customer contract or from the regulatory regime governing the end product, and both usually run longer than the pack's production life. The end product stays in service after the pack stops being built. In some categories it stays in service for a very long time.
Two traps here. First, the clock usually starts at shipment or end of production, not at project close, and project close is the date everyone remembers. Second, retaining the documents without the index is close to retaining nothing. A folder of correctly retained PDFs with no mapping to pack revisions is a folder of question marks. Retention applies to the index too.
The one-day test
Here's how I check a program's filing without an audit. Pick a shipment date at random. Ask someone on the team, cold, for the certificate covering packs shipped that week. Time it.
If it takes more than a few minutes, it's a filing problem. If it takes more than a day, it's a filing problem that has been mistaken for something else for a while. Document requests that can't be answered inside a day or two during an audit are almost never compliance failures. The product is fine, the tests passed, the listings are live. The team just can't find the paper.
Worth saying plainly, because it's why this keeps happening: filing failures and compliance failures feel identical from the outside. One costs you an afternoon. The other costs you a market.
What I ask suppliers for
Three things, asked at drawing release, not at the end of the program.
Send the compliance set when the drawing is released, not when the project wraps. A certificate that shows up three weeks before volume production has no room left to be checked against the drawing it supposedly covers.
Name the files to the convention in the drawing package, or expect them to be renamed on arrival. I rename into our convention at intake, every time, including when the supplier's naming is better than ours. One logic in the folder beats two.
When a document is revised, send the new one and the one it replaces in the same package. That's the request that gets forgotten most often, and it's the one that decides whether you'll have a superseded document to produce later. Ask for it explicitly, every time, and keep asking after the first time a supplier sends only the new one.
Where it still goes wrong
Even with all of this, a few things slip through.
- Two people saving to two places, so two folders drift apart and nobody knows which one the auditor looked at last year.
- A certificate that arrived as an email attachment and was never saved anywhere with a name.
- A certificate issued to the cell or module maker rather than the entity you contracted with. That's legitimate, and it also means the holder field in your index should name the module maker, not your supplier.
- A model designation on the certificate that covers the base model while the variant you ship carries a different suffix. The coverage may still be correct. The file needs to record why you believe so.
- Renewal dates nobody tracks until they lapse.
- A design change that someone decided didn't need new testing, with no note in the file saying who decided and when. Whether a change triggers retesting belongs to engineering and to the standard. Recording the decision belongs to the file.
The pass condition
The goal is a boring audit. Question asked, file pulled, question answered, next question. Nobody in the room learns anything about your compliance program, because there's nothing to learn.
I don't get to claim a perfect record on this. I've sat through the day-and-a-half version more than once, usually on a program someone else built. What changed for me was realizing the fix isn't more diligence. It's structural. The certificate was never the problem. The certificate had no address, and I was expected to remember where it lived.
Neither certfinal.pdf nor certfinal_updated.pdf is final. There is no final. There's only the one that matches the revision you shipped, and the one it replaced.
