Last time, I described an AI-enabled system that incubates cells for advanced therapies. It watches the cells as the process runs and recommends the machine’s next move. The goal: fewer failed cultures, more therapies for patients, and lower cost.
To make a system like that work under regulation, I introduced a second validation lifecycle that grew out of our own work: building advanced-therapy processes and building AI governance into Minerva’s quality system. I call it Context Language Validation, or CLV, because it concerns the way the context that feeds the AI is written and controlled. CLV has five stages: Define, Lock, Apply, Monitor, and Review. This edition is about Lock, the stage the quality professionals I talk with feel most sharply, because it relates to a rule they already live by: document control.
Picture the system running. It images the cells and compares each image to a bank of reference images labeled with a corresponding description, classification, and expected action. From those images and labels, the AI recommends the next move, and a person approves or overrides that recommendation before the process continues.
Now suppose the AI flags a run drifting out of range. The scientist opens the images and sees the problem in images the model had previously classified as healthy. A few steps back, the model had recommended no action. But the cells were not healthy. They had begun to clump in a pattern not seen before. It should have been caught, but the model let it pass.
The scientist knows the technical fix: relabel those earlier images as needing intervention, name the intervention, and add the new pattern to the bank so the model catches it next time. The fix seems obvious.
It is not.
The science may be sound, but anyone who has worked inside a quality system knows the rule: never edit a released document in place. The context for an AI system is a controlled record. You revise it, route it through change control, approve it, and release a new version. The old version stays on file, exactly as it was. Nothing is overwritten. Everything is versioned.
So the urge to improve the bank is right. But fixing it in place is exactly what Lock does not allow.
Here is why that matters more than it appears. The bank is not just pictures. It also holds the labels in a language the model uses: healthy, early stress, late stress, abnormal, unknown. It holds the rules and thresholds that separate one state from the next, decide when the model acts, and decide when it asks for help. It holds the action tied to each state. Running through all of it is language: the words that define each state. They must mean the same thing everywhere in the bank, and they must be used consistently for equivalent conditions.
Adding the new pattern is not just adding a picture. It adds language to almost every part. If the scientist uses different words from the states around it, the model may process the new condition differently than intended. Use a synonym for a state already in the bank, and the model may blur the two. That is why the change is never simply “add these images.” It is this: add the images, keep the wording consistent with what is already there, check how the model processes it, validate the new state, adjust the borders it touches, set its threshold and action, and lock it all as one version.
There is a deeper lesson here. The model did not fail because a picture lacked a label. It failed because it was confident about something it had never seen, reading a new pattern as healthy instead of admitting uncertainty and escalating it. So what gets locked is not only what the model knows, but how it behaves at the edge of what it knows. A pattern it has barely seen should make it less confident, not more willing to guess.
Teaching it the new condition is half the job. The other half is proving that the new wording works as intended by testing it against the model before it goes live, not just trusting it on paper.
Why keep the old version at all? Because a description that looked right but tested wrong is a finding, not waste. Kept with the reason it failed, it stops the next person from walking into the same dead end. That record is provenance: where each version came from, why it changed, how it tested, and which approved or superseded version was used at each point in time. Language and test results travel with it.
In CLV, the locked version is treated like a controlled parameter. A change is not a quiet edit. It is a proposed new version. It requires impact assessment, review, approval, and release control. The audit trail records which version was live, who approved it, why, and the wording and test results behind it.
Does every small discrepancy reopen the whole context language validation? No. How much review it needs depends on risk. Because this system is meant to help produce material for patients, its governance will be scrutinized. But the regulatory mechanism depends on intended use, claims, classification, and whether the AI function is reviewed as part of an AI-enabled device software function.
If the AI function is reviewed as part of an AI-enabled device software function, a Predetermined Change Control Plan may define approved boundaries for certain iterative modifications. In other settings, the mechanism may be change control, model governance, data governance, and continued performance monitoring. Either way, learning cannot be uncontrolled. A plan can define how specified model or context updates are developed, tested, approved, and implemented within predefined boundaries.
If a change stays within an approved modification plan, predefined acceptance criteria, and the applicable change-control pathway, it may be implemented without reopening the entire validation. Outside those boundaries, it becomes a larger change. Speed still matters. A change can move quickly from one approved version to the next, or it can hand a step back to a human when the system has not yet earned the right to run it alone.
This is where Lock earns the word validation. Validation means knowing the whole path: the context, how the model uses it to produce an output, and the evidence that new wording produces the result expected. A system that changes but cannot show how it changed, including the words it changed from and to, is not validated. It is only asking you to trust that the changes were good.
With CLV, an auditor sees not only what the model is told today, but why the wording was chosen, how it tested, and the approved and superseded context versions retained in the record. Nothing controlled is overwritten or lost from the record.
CSV locks the machine. CLV locks what the machine is told, and how it is told.
You supersede with provenance.
Even the language.
That’s the Minerva Way.
