Fixing the systems around this work has always interested me. I introduced paperless reporting to the PPE team inside a test house. I built the evolving workflow trackers that certification bodies still use today. Both came from the same frustration: the system in front of me was slow, it was not built for the job, and it left more room for a person to make a mistake than it needed to.
So when I set up on my own, I was not asking whether to use AI. I was asking what it should be reading from. This is how I answered that, and it may be a useful look at how I use mine.
What goes into a second brain
Start with what it holds, because the obvious part of it is only part of it.
The obvious part is the technical material. Certification body requirements. Standards by product category, and which standard a given protection claim depends on. Document types: what each one is, who produces it, and which clause or body requirement demands it.
The part people leave out is everything I know that never got written down. What a particular body pushes back on. The issues that come up again and again on a submission. The fix that worked last time. The question an assessor asks when the evidence is thin. Observed lead times, which are not the published ones.
That second part is what separates a reference library from something that behaves like an experienced colleague. It is also what walks out of the door when someone leaves.
I have watched people with twenty and thirty years in a technical team leave, and it is felt the next day. Not in a month. The next day. The plan is always a handover on the way out, and that is close to impossible: a leaving period goes on closing out their own work, and the new starter who needed to sit beside that person for a long stretch gets a document instead.
None of this is only about people leaving for good, either. Your specialist is on holiday for a fortnight, or off sick, or buried in another project until Thursday. The question in front of you still needs an answer today, and it is their answer you need. Holiday and sickness come round far more often than someone leaving does, which is why this version matters more day to day.
Where it lives matters less than people starting out tend to think. Mine is a folder in Obsidian: plain text files, simply linked, in what it calls a vault. Notion or Logseq would do the same job with more structure bolted on, and a plain folder of Markdown files with no application at all is a legitimate place to begin. Which tool you pick barely matters. What you put into it does.
The four layers
Most knowledge projects never get past collecting. The business piles everything it has into one place, adds a way to search it, and stops there. The pile is quicker to get into afterwards. It is no better sorted than it was.
A second brain worth the name has four layers. The first is the facts: what it knows, the sourced material described above. On its own that is the register layer, a well organised filing cabinet and nothing more.
Then how it judges: the written checks. What a complete document set looks like for this product on this route, and which questions have to be resolved before anything goes near a body. Facts tell you what is true. Whether the work in front of you is good enough is a different question, and the checks are what answer it.
Third, what it can run, the procedures, written down tightly enough to run the same way every time. Gather the evidence, check every public claim against what supports it, compare the documents in a set against each other and list every place they disagree. That last one catches what a person reading through misses, because a person reads a set in order and forgets page four by page thirty.
Last, what it learns. A comment from a body gets reviewed and goes in once, and nobody works it out a second time. That is what lets the documentation adapt, to a body's stated preferences and to the things it raises that it has never written down.
The layers are connected. Facts feed the checks. Checks run inside the procedures. The procedures produce corrections. The corrections go back into the facts, with a source attached like everything else.
One comment becoming a check
Here is what that fourth layer looks like doing its job, from an actual submission.
A pair of gloves went in for certification. The technical file cited EN ISO 21420, the general requirements standard for gloves. It was published. It just was not harmonised, and would not be for years yet: that only changed in June 2026. Until then, EN 420 stayed the harmonised standard in force.
The certification body I will call Body A came back with one comment. It wanted a short section added to the documentation, acknowledging that gap: that the file was working from EN ISO 21420 while EN 420 was still the harmonised one. It didn't specify exact wording. It wanted the file to say, in effect, that the manufacturer knew it was working from EN ISO 21420 and knew EN 420 was still the one in force.
The client added it, and the certificate was issued. Job closed. Most consultancies stop there. I wrote the comment down instead: what Body A had asked for, on what kind of submission, and for as long as that harmonisation gap lasted.
Three months later, a second pair of gloves went to Body A. Same standard cited. No acknowledgement section. The check I had written fired before the file went anywhere near the body: does it cite EN ISO 21420, and if it does, has that section gone in? It went in. That documentation was submitted. Body A never raised it, because there was nothing left to raise.
Here is the part that makes the record worth keeping rather than just remembered. Around the same time, Body B was raising the opposite point on a similar file: it did not need the acknowledgement section at all, and it did want every EN 420 reference gone, with the current standard on anything newly issued. Same gap, two bodies, two different instructions. Both went in as what that body asks, not as a rule either of them could claim.
If I had only remembered Body A's comment, I would have carried it straight onto Body B's file and been wrong in a new way. The record is what stopped that.
Inside the first layer
The facts are not one big document. They are families of records, and every record in a family answers the same list of questions, in the same order.
Take a certification body record. It answers what they test or certify, what they want submitted and in what shape, hard restrictions such as a body that only accepts its own test reports, what they are known to push back on, and their re-review behaviour: whether a second look carries a surcharge, how many rounds you get inside the fee, and how long the second pass takes. It can decide a timeline on its own, and it is rarely published.
A standards record is a different shape. It starts with which standard a given protection claim depends on, and that part is public, and on its own worth very little. What sits on top of it is the rest of what I know: where the test method gets interpreted differently depending on who is running it, the clause that reads like nothing and keeps coming back as a rejection, the bottleneck that shows up on the same product type every time. None of that is in the standard. You get it from having been on both sides of it for years.
Then there is the claims layer, whose job is to tell the difference between a claim the evidence supports and a claim that quietly goes further than the certificate allows. The grey ones are the dangerous ones, because they are the least likely to be caught in-house and the most likely to be challenged. It works the other way too: pull the facts out of the technical documentation and the certificate, and what comes back is the strongest honest version of what the product does, which is usually better marketing than whatever was on the page before.
Every record of a type carries the same questions, whether or not they have been answered yet. An unanswered question sits there looking like an unanswered question, which is what makes the next section possible.
The gaps are the useful part
There is no third state. A fact is confirmed, or it is an open gap. No "usually", no "typically", no "in most cases". A hedge reads as knowledge and has nothing behind it.
Because the same questions sit on every record, the unanswered ones are visible and you can count them. You can see that the claim map is filled in for one product family and empty for another. You can see which body you have solid submission knowledge for, and which one you have been guessing about. The brain's completeness is a count of its open gaps, not of its documents.
Gaps open in three ways. Somebody asks a question the brain has no rule for, and the miss gets recorded instead of improvised over. A dated fact goes stale, because a standard was amended or a body changed its policy. Or the question was never answered in the first place.
Once you can see them, you close them on purpose. Some of that is sitting down with the person on the team who knows, while they are still there. Elsewhere it means going back to the original document with a specific question in hand, or asking the body itself for a written answer, which is worth doing more often than people do.
The difference is that you work through a list, instead of finding the gap halfway through a submission.
How a question gets answered
This part is deliberately unglamorous.
A question goes to a rule, and the rule says which record to open and which question on it to read. Ask what a body requires or pushes back on, and it opens that body's record and reads what it wants submitted and its restrictions, then, separately, what it tends to raise anyway. It returns those as they stand, and names every gap among them rather than filling them in.
None of this needs an exotic setup to run. Once the notes have grown past what you can find by typing the right word into a search box, you need something that finds a passage by what it means rather than what it says: a search index, sometimes sold as a vector database. And you need something that can read the records, follow the rule and hand you an answer: a model, Claude, GPT and Gemini are the ones most people meet first, working as an agent given permission to open the file it actually needs. Opening the vault in Obsidian does not, on its own, give any of that access. You wire it up deliberately, or it does not happen.
Most of the time, though, I am not asking it anything. That is the part I did not expect. It comes to me. If something I have put down does not match what the records hold, it comes back to me during the check without my asking for a fact check. Corrections included, which do happen, because I am human. It is closer to having a room of specialists next to you than a tool you query.
Three laws govern all of it. Answer only from the records: if something has not been confirmed, the answer is that it has not been confirmed, never a best guess. Cite the record, so anyone can check it in one click. Respect the internal-only flags: some facts must never reach a client document or a public page, however true and useful they are.
And when no rule matches the question, it does not improvise from general knowledge. It says so, logs the same kind of gap described above, and tells me what would close it, an interview with me or a document to read in. That is the behaviour I would fight hardest to keep. A system that tells me when it does not have something is worth more than a thousand conversations with a general model that has no context and will give you an answer regardless.
How it stays correct
New knowledge comes in through one door: an interview transcript, a document, a body's written comment. It is stored verbatim and never edited afterwards, and only then worked into the records with the source cited.
One fact has one home. Everything else points at it. Nothing gets restated in a second place where the two copies can drift apart and both look authoritative. When a gap is closed, the source goes in with it, in the same edit; no source, no change. When a fact is retired, it comes out of the records and into a dated change log.
What the AI may never do is write in something it made up. A fact can only go in carried across from a cited source, with the citation attached. An answer the model composed is never allowed to become knowledge on its own say-so. Without that rule, a system answers a question slightly wrong, the answer gets stored, and later it is quoted back as though somebody had checked it.
Getting it out of my head
The structure took a fraction of the effort. Filling it took the rest.
Ask an experienced person what they know and you get the headlines. Hand them a blank document and you get a thin version of a rich thing. The rest only surfaces when a specific situation pulls it up, which is the same reason a handover in a leaving period does not work.
So I had AI interview me instead. Long structured sessions, one body record or one checklist at a time, working through specific products, specific submissions and specific comments that had annoyed me at the time. It kept pulling on a thread until the answer got concrete, and dragged up things I had not thought about in years because the question was specific enough to reach them. Every transcript went into the source store first, verbatim.
Then every statement got carried back to a source. Does a standard say this, or did a body put it in writing, and when. If neither, is this just me, on a date, from experience. Plenty of it could not be confirmed from anything, and that was the useful part: it went in as an open gap, and the gaps became the work list.
The transcripts turned out to have a second use. There is publishable material sitting in them, in my own words, said the way I would say it out loud. I now rely on it.
The version most businesses are running instead
I would assume most compliance consultancies are using AI somewhere by now. In a lot of larger businesses the response has been narrower: Copilot gets switched on because it is already in the 365 package, everyone is told to use it, and that is the strategy.
Which is fine for what it is. It will help write the email and tidy the document. Ask it which of the four versions of that document is the one you are allowed to work from, and you are on your own. Years of documents on a shared drive is not a knowledge base, and a document management system is not a knowledge system either. Neither gives a new starter a head start, because neither one knows which of the things it is holding is true.
I tested the other end of this too. I asked five AI platforms to create a technical file for a motorcycle PPE jacket and told them nothing about the product. Not one of them asked a question. All five produced a document straight away, and all five produced a template in square brackets waiting for me to fill in. The thing I asked for was still my job, with somebody else's structure now wrapped around it.
With enough back and forth you could probably get a technical file through. Two questions survive that: can you read it, and do you know what is in it well enough to answer for it when the body comes back with comments.
Where I notice it most
Writing is where this pays itself back fastest.
I have written white papers, articles and web content for certification bodies. That copy gets reviewed seriously; copywriters and marketing teams go through the structure and the tone, line by line, and they are good at what they do. None of them check whether the technical content is right. It is not their job. So the part of the piece most likely to cause a problem later is the part nobody in the chain is reading for accuracy.
Stare at something you have written for long enough and you go blind to it. Nobody holds all of it at once, and the longer you look the less you see. Now something else is looking. The checks go over what I have written and pull me up where it has drifted from what the evidence supports. It catches me regularly. My memory is not going to beat a well prepared knowledge base on recall or on speed, and it took me a while to stop being irritated about that.
What it is, and what it is not
I built Trace Core on this. It holds the requirements, the document rules and the reviewed feedback behind my documentation work. Trace Core runs the checks, and I sign off everything that leaves Trace.
The limits matter as much as the capability. It holds what was decided and why. It does not make the judgement call. It does not decide whether a product conforms, and it approves nothing. Client product information stays with that client's job and never enters shared knowledge.
Where this goes next
Part 2 is what you do with all of it: taking a product, a route and the body assessing it, and building the documentation set that goes with them.
There is no one-shotting in it. I put the information in. The set gets prepared from that. A countersigner goes over the set and raises comments back to the preparer, if there are any. Then it goes to a signatory to check again. Different processes at each stage, and different personalities, because what I am running is an emulation of the certification body, on my own machine, before the real one ever sees it.
The signatory stage is a check on the work, not the certification decision itself. I do that part.
Part 2 is how those steps are built, and why handing an agent a prompt does not get you there.
