Part 1 was the foundation: what a second brain holds, and why I keep an open gap visible rather than guess at it. Part 2 is what happens once that brain has something to say.
Could I write this myself and check it once, faster? Yes. Is it worth running the extra checks anyway, through a lens I do not naturally use myself? Absolutely.
There are products out now that give a preliminary view of the regulations that might apply, from a photo. Useful enough for a toy or a generic consumer item, where the categories are broad and the requirements are public. A specialist product needs the construction detail behind it, the materials, the build, the specific way it is put together, and an image was never going to show that.
What I am describing here is different. It does not start from a photo. It reads what I have already prepared, checked against what a certification body would look for, before that body ever sees it.
Not the certification body
I want to be direct about the boundary before anything else. I am not replicating a certification body's decision. Nothing in what follows can deem a certificate void, issue one, or replace the body's own review. What it does is run certification-body-style checking on the document set at an advanced stage, before it is submitted, so fewer things arrive at the body for the first time.
That is not the same as preventing everything. Non-conformities still get raised, and they will keep getting raised. I am not pretending otherwise. As much as I would like to eradicate them through in-depth preparation, I am not in control of an assessor's decisions, or of requirements that can change at any point. What changes is what happens once one lands. It goes back in. It gets reviewed, scoped to where it actually applies. Once that is done, it becomes a check for next time, the same way a body's own review report is something you read before the next submission, not left in a folder and forgotten.
The four passes, and what is actually happening inside them
I set out the shape of this on the How I work page. It follows a shape a certification body would recognise: someone prepares it, someone else checks it, and a signatory reviews it before it reaches whoever has final say. I built the same shape into my own workflow, with the final say always mine, before anything reaches theirs.
What that page does not show is what is happening between the passes. Each one checks something specific and hands its findings to the next. It is not one process asking a question and getting an answer back.
- Preparation pass. Builds the set from what I have given it, and raises a question wherever information is missing.
- Evidence and consistency check. Tests every claim against what supports it, and lists everywhere the documents disagree with each other. The same way a countersigner goes back to a preparer with comments before anything moves on.
- Review of outstanding questions. Checks that every one of those questions has actually been closed. The way a signatory checks a set before it reaches the person with final authority over it.
- Final release. Mine. I read the work, make the judgement calls, and release it.
Every pass records what it found, not just what it fixed, the same way a body logs its own findings in a review report so the next submission does not repeat the last one's mistakes. I wanted the same discipline running on my own side, before anything leaves me.
I do not hand it a single prompt and take the answer as finished. It runs as a sequence of checks, built the same way on every set, logging what it finds at each stage. If a question is not closed, it does not get waved through. It comes back to me, and I decide whether it is answered, accepted as it stands, or needs to go back a stage. Nothing moves to release on its own.
While it runs, I move on to the next job, the same way I would after submitting a set to a certification body and waiting on their own assessor.
One intake, not four separate write-ups
In my own setup, I put every claim and construction detail into one place myself: seams, SSL ratings, materials, the way a product is actually built. That intake sits on its own standard-specific page inside my CRM, structured directly from the point a client first fills out our intake form about their product. From that single record I can generate a test request form, a technical file, a declaration of conformity and label mockups, without writing the same fact out four times in documents that then have to be kept in step with each other by hand. Instructions for use go through the same checking, even where the instructions themselves are client-supplied rather than something I have generated, the same as the label sometimes is.
That matters more than it sounds like it should. Document sets do not usually go wrong because someone got a fact wrong once. They go wrong because the same fact was typed in four times, got corrected in one of them, and the other three were never touched. One intake, checked once, reduces the risk of that failure mode instead of catching it after the fact.
It also changes the order things get finished in. The documentation does not wait for testing to conclude before it starts. It is ready alongside it. When the reports come back, updating the test report references is usually what is left, and anything the results actually change gets revised too, rather than writing the file from a blank page under a deadline. The final technical-file check is then straightforward: does what is in the file match what the reports say. That comparison is one of the final checks before anything is released.
I am describing my own workflow here, not a product I am selling. It is set up around PPE, around the bodies I work with and the way I work with them, and it took real time to build.
I am still the one preparing it
I want this stated plainly, because it is easy to read the last two sections and assume otherwise: I am the one preparing the information. Every fact in a technical file started as something I put in. What runs on top of that checks what I have written. It does not write anything itself. Generating a test request form or a technical file from that intake is drafting it into the right shape, not deciding what goes in it. It finds where what I have written has drifted from what the evidence supports, and it tells me before a body does. It does not decide what the product is, and it cannot write a claim I have not already made myself.
I do not go looking for that correction. It gets brought to me, naturally, as part of the process, whether that is a technical file, an article, or a page of website copy. I still miss things. Everyone does. I have worked with people who had thirty years in a technical team and still missed things, on a bad week or a rushed one. Experience cuts how often it happens, but it never removes it completely. The checking stage now gives each set another review before I release it, which is the part that changed.
When the ground moves
A certification body's requirements do not only change when a standard or a regulation is updated, or a body writes down a new position. Some of it is never written down anywhere: what a body has quietly started preferring, or how one particular assessor works, which does not carry the same weight as a formal requirement and is not treated as one. I have worked to more than one body's requirements for the same kind of product, and they have not matched.
That is why feeding a finding back in, the way I described above, matters more than getting everything right first time. Whether it is a body's stated position or one assessor's own way of working, it gets recorded and checked for how far it actually applies. It only changes what goes into the next set for that body once that is confirmed, not on the strength of one comment. The alternative is relearning the same lesson on every submission because nobody wrote it down the first time it came up.
What else runs through this
The checking does not have to stop at technical documentation. You can run marketing copy, website content and social posts through the same passes, wherever a technical or certification claim is doing the work in them, built from what the certificate and technical file support and checked before release, the same as everything else.
Not a product, and not yet a service
A small compliance team could set up something like this for itself, with the knowledge it already has and without a large tooling budget, the same way I built mine starting from my own second brain in Part 1. I would start the same place I did: interviewing the people who actually know the work.
Where this goes for Trace is not decided, and it is not the subject of this piece.
Where this goes next
Part 1 built the knowledge. Part 2 is the checking that runs on top of it, before anything leaves me. Part 3 is what happens after a set has been through this enough times: how every pass, fail and correction, once it has been reviewed and scoped, becomes training rather than just a fact in a record, and what that means for bringing someone new into a technical team.
