This is the third essay in a series about AI alignment.
The first two essays looked at guardrails and the cost of learning. I was working toward a distinction that still seems important to me, although I'd frame it somewhat differently now.
We can test an AI system before deployment. We can establish constraints, evaluate known failure modes, document expected behavior and decide that the system has met whatever standard we've established for release. All of that matters. What we can't establish in advance is that we've represented every situation the deployed system will encounter.
The world gets another turn.
People use systems differently than their designers expect. New capabilities interact with old ones. A behavior that looked safe in isolation creates a problem when placed inside a larger workflow. A safeguard blocks something nobody realized it would block. An unusual user discovers a case that wasn't represented in the evaluation set.
None of this means the original evaluation was useless. It means the evaluation had a boundary.
That's where I think alignment becomes a practice.
Not because alignment can't include stable properties or constraints, and not because every decision has to remain permanently open. It's a practice because operating the system keeps producing evidence, and someone has to decide what to do with that evidence.
That distinction changes how I think about guardrails.
I once treated guardrails and learning as opposing approaches. A guardrail prevents a behavior, while learning supposedly requires encountering the consequences of behavior. From there it's easy to conclude that preventing mistakes also prevents the system from learning why those mistakes matter.
I don't think that follows.
Some mistakes should be prevented.
If we already know that a particular action creates an unacceptable risk, allowing the action merely so the system can experience its consequences would be a strange definition of learning. We don't teach every human lesson that way either. Much of what any of us knows arrived through instruction, observation, inherited practice and warnings from people who encountered the consequence before we did.
Guardrails can carry some of that accumulated knowledge.
The interesting question is what happens when the guardrail encounters a situation its designers didn't anticipate.
Perhaps it blocks something harmless because the new situation resembles a dangerous one. Perhaps it permits something dangerous because the relevant distinction wasn't represented in the rule. Perhaps the boundary is sound but the surrounding interaction makes it difficult for a legitimate user to accomplish something safely.
Now the guardrail itself has produced information.
The practice begins with noticing.
That sounds easier than it is because organizations are very good at turning unexpected behavior into categories that require no further thought. The model failed. The user misused it. The safeguard worked. The test passed. The incident was resolved.
Sometimes those descriptions are accurate. The problem is treating the category as the end of the investigation.
If a system behaved differently than we expected, I want to know why we expected something else. What information was available? Which assumptions were embedded in the evaluation or safeguard? Did the system fail to make a distinction we thought it could make? Did we ask it to make a distinction that isn't actually available from the information it had?
Those questions may produce a model change, a new evaluation, a different interface, another safeguard or no change at all. Investigation has to preserve the possibility that the original behavior was appropriate and our expectation was wrong.
That's important because feedback doesn't interpret itself.
A complaint isn't proof of misalignment. Neither is the absence of complaints proof that the system is aligned. Users have partial views, developers have partial views, evaluators