The second brain: where a compliance team’s knowledge lives

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 insight into 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 regulation-level rules that apply regardless of who is assessing.

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. The order a set gets read in. 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 that they hand their knowledge over on the way out, and that is close to impossible. A leaving period goes on closing out their own work. The new starter who needed to sit beside that person for a long stretch gets a handover document instead, and learns the job from whoever is left.

In the places I saw this happen there was nothing else in place. Nothing written down at all.

None of this is only about people leaving for good, either. Your specialist in one area 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. Would it not be better to keep moving?

Holiday and sickness come round far more often than someone leaving does, which is why this version matters more day to day.

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, and the facts are only the first.

What it knows. The sourced facts described above. This is the register layer, and on its own it is a well organised filing cabinet.

How it judges. The written checks. What a complete document set looks like for this product on this route. What makes a claim unsupportable against the certificate behind it. 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.

What it can run. The procedures, written down tightly enough to execute the same way every time. Prepare the set. Check every public claim against the evidence that supports it. Compare the documents in a set against each other and list every place they disagree. That last one is there to catch what a person reading through misses, because a person reads a document set in order and forgets page four by page thirty.

What it learns. A non-conformity raised during certification is reviewed and goes in once. Nobody has to work it out a second time. That is what lets the documentation adapt. To a body’s stated preferences, to the things it raises that it has never written down, and down to the way an individual assessor works and what they look at hardest. Each round adds to it, so what goes in next time is closer to what that body wanted before anyone asked.

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.

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.

A certification body record answers what they test or certify and in which categories, what they want submitted and in what shape and order, hard restrictions such as a body that accepts only its own test reports, what they are known to push back on, observed lead times, and their re-review behaviour.

That last one deserves a sentence. Re-review behaviour is what happens when work goes back for a second look: whether there is 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 starts with the standards for a product category and which protection claim depends on which one. That part is public, and on its own it is worth very little.

What sits on top of it is the rest of what I know about that standard. Where the test method gets interpreted differently depending on who is running it. The clause that reads simply and keeps coming back as a rejection. What fails, and the fix that has worked. The bottleneck that shows up on the same product type every single time. Which parts of it a body will look at hardest, and which parts nobody will query.

None of that is in the standard. You get it from having been on both sides of it for years, and it is the reason two people can read the same document and produce very different submissions.

Then there is the claims layer. Its 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. That 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, and the entry stops being current. 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. Where neither settles it, ask 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, accepts, or pushes back on, and it opens that body’s record and reads three of them: what they want submitted, their restrictions, and what they raise most often. It returns those as they stand, and it names every gap among them rather than filling them in.

If the question is which standard a given protection claim depends on, it opens the standards record for that category and reads the claim map. If that one has not been confirmed, it says so.

Ask what goes into a technical file, and it reads the document type table, then tells you that anything a particular body wants on top of that is not in this answer, and points you at that body’s record. The general answer and the body-specific answer are deliberately kept apart, so neither one overwrites the other.

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. I am not going hunting through folders, because the checking is built into the process rather than being a thing I have to request. 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. Every answer names the record it came from, 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. The flag sits on the record, so nobody has to remember it at the moment of writing.

And when no rule matches the question, it does not improvise from general knowledge. It says the brain does not cover this, records the miss as a specific gap, and tells me what it needs to close it, whether that is an interview with me or a document to read in. The absence is obvious, which is the only reason it gets fixed.

That last behaviour is the one I would fight hardest to keep. It does not invent facts, and there is no route for a generated answer to become a record. 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 is it 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. The history lives in the log. The records only ever hold what is true now, which is what makes them safe to read an answer from.

The AI does write into this. What it 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. Without that rule, a system answers a question slightly wrong, the answer gets stored, and later it is being 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.

Expertise is mostly not conscious. Ask an experienced person what they know and you get the headlines. The rest only surfaces when a specific situation pulls it up. Hand them a blank document and you get a thin version of a rich thing. It 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. It 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. Did a body put it in writing, and when. Or is this 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.

AI did the extraction and the structuring, and it is good at both. It was never the authority on whether any of it was true.

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. A document management system is not a knowledge system. 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.

I am writing that research up properly in a field note.

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.

Have you ever stared at something you have written for so long that you go blind to it? That is the real problem. 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 written checks. I review everything before it 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. It is not a signature, and it is not a certification decision. I do that part.

Part 2 is how those steps are built, and why handing an agent a prompt does not get you there.