CAPA closes on the document, not the answer

Every regulated company has a drill for the moment something goes wrong. A finding gets raised. Someone holds the problem in place, works out the cause, fixes the cause, and checks later that the fix held. This is the best rehearsed loop in quality work. It runs on things you can hold: a batch, a step, a supplier, a file.

Then an AI assistant gives one of your people a wrong answer, drawn from your own content, and the loop has nothing to grip.

What CAPA assumes

The terms are tight. Corrective action removes the cause of a fault so it does not recur. Preventive action deals with a cause that has not caused a fault yet. Correction is the quick fix to the thing in front of you. ISO 9001 carries corrective action as a rule. ISO 13485 carries it for medical devices. ICH Q10 names it as part of a drug quality system.

Under all of those, four things have to be available before the loop can run.

• The nonconformity was detected and written down.
• The thing that went wrong can be contained.
• The cause can be traced to a source.
• The fix can be checked for effect later.

An AI answer fails all four. Not partly. All four.

Nothing was detected

A bad document leaves a trail. It has a number, a version, an owner and a change history. Somebody notices it and raises a record. An answer leaves none of that. It appeared in a chat window, got read, and got used. In most deployments there is no artifact at all, so nothing triggers the process that would have caught it.

Nothing to contain

Containment means holding affected units in place while you work. An answer has already moved. It went into a client email, a slide, a submission, a ticket. There is no recall path, because nobody knows who received it. You cannot quarantine something you cannot list.

No traceable cause

Root cause for a wrong answer has a short list of candidates. The source was wrong. The source was right but had been superseded. Two sources disagreed and the assistant picked one. The material was never approved in the first place. Or there was no approved answer at all, and the model wrote something that sounded right.

Telling those apart requires knowing what the assistant read, and at which version, at the moment it answered. Very few deployments can reconstruct that a week later.

Grounding does not settle it

Grounding the model in your own documents does not settle it either. A preregistered study of commercial legal research tools built on retrieval found that the leading products still returned false information between 17 and 33 percent of the time, against vendor claims of eliminating it.

Nothing to check

The effectiveness check is the step that closes a CAPA. You come back after a set period and confirm the action worked. So you correct the source document, and you close the record.

The correction lands on the document. It does not touch the answers already derived from the old version, and nothing anywhere lists them. The check passes. The wrong answers are still in circulation.

The trail regulators already expect

None of this is a new expectation dressed up for AI. The MHRA guidance on GxP data integrity treats data governance as something that runs across the whole lifecycle, not just at the point of filing. EU GMP gives documentation a chapter of its own.

What the AI Act asks for

The EU AI Act goes further for the systems in its scope. Article 12 requires high risk AI systems to allow automatic recording of events across their lifetime, so that the way the system operated can be traced. That is a record of what happened, kept so somebody can go back to it.

Cognatum does not confer compliance with any of these, and no software does. What software can do is supply the evidence your own reviewers ask for.

What has to be true for the loop to close

Four things, and each of them is a property of the knowledge base rather than of the model.

The answer has to be an event

An answer needs to exist as a record: what was asked, what was returned, and which entries it drew on. Without that, detection is luck.

The record has to be point in time

It is not enough to know which entry an answer came from. You need the state that entry was in when the answer was given: the version, the named approver, the date, and the source behind it. That is what turns a vague complaint into a traceable cause.

A change in a source has to raise a flag

When a source changes, everything downstream of it is now suspect. Cognatum detects the change and tells you which entries depend on it. It does not quietly rewrite them, and it is not always current by itself. The revision queues for a person, and consumers keep the last approved version, with its date visible, until somebody signs off.

Conflicts get surfaced, not settled by the machine

Where two approved entries disagree, the answer is that they disagree. Cognatum holds both apart and routes them to a named person rather than picking the more recent one. While that flag is open, no contested version is served as approved.

A knowledge base problem, not a model problem

Cognatum is a knowledge base. One governed home for what your company knows, served to people and to AI systems, with a named approver, a date and a source on every entry. It runs the Cognatum Knowledge Loop: eight steps in four phases, where AI does the capture, structuring, cleaning, enrichment and improvement, and a person holds the Approve gate.

Information stays where it lives. Departmental repositories are normal and fine. The flow is bidirectional, so you point Cognatum at the systems you already use instead of moving anything into it.

What it comes down to

Your company's knowledge isn't missing. It's unusable. Cognatum changes that.

None of this requires a better model. It requires the thing the model reads to have a record behind it, so that when an answer is wrong, there is something to correct, something to contain, and something to check.