Alignment Is a Learning Property, Not a Specification

This is the fourth essay in a series about AI alignment. The earlier essays approached the problem from different directions: guardrails, the cost of learning, and the idea that alignment is better understood as a practice than as a state. That leaves a practical question. If alignment is something we maintain rather than something we finish, what exactly are we maintaining?

One answer is behavior within constraints, and that's important. There are things an AI system shouldn't do, and some boundaries should be established before deployment rather than discovered experimentally through harm to users. Evaluations can identify known failure modes, guardrails can prevent classes of dangerous behavior, and monitoring can reveal when those protections aren't behaving as expected. The problem begins when passing those checks becomes evidence for a larger claim than the checks actually establish.

An evaluation tells us how a system behaved under the conditions represented by the evaluation. Deployment introduces other conditions. People ask questions the designers didn't anticipate, different capabilities interact, users misunderstand instructions, and the model encounters unusual combinations of otherwise familiar situations. A safeguard that worked well in testing may produce an unexpected effect when thousands of people encounter it from different contexts. Now we have new evidence, and alignment work has to be capable of receiving it.

That changes the role of guardrails considerably. A guardrail doesn't need to teach a model the complete reason a boundary exists in order to be useful. If a system is about to expose someone's private information, I'm not particularly interested in letting it make the mistake so it can experience a meaningful learning opportunity. Prevent the disclosure, then investigate why the system approached the boundary in the first place. Prevention and learning aren't opposites. They operate at different parts of the problem.

This also makes me cautious about distinguishing too cleanly between a system that is merely constrained and one that genuinely understands. With current AI systems, understanding is difficult to establish from behavior alone. A model can produce an excellent explanation of why a safety rule exists and still behave inconsistently in another context. It can also give an unconvincing explanation while producing behavior we consider appropriate. Self-explanation is evidence, but it isn't direct access to whatever internal process produced the answer.

So rather than asking whether the system possesses alignment somewhere inside itself, I'd ask questions we can observe more directly. How does it behave across variations of the same problem? What happens when relevant context changes? Does a safeguard block the harmful part of a request while preserving useful alternatives? Where do users repeatedly encounter refusals that don't match the actual risk? Where do evaluations say the system is safe while deployment reveals behavior we didn't anticipate?

Those mismatches are valuable, although they don't interpret themselves. If employees repeatedly bypass an approved AI tool and use something else, perhaps the approved system has been constrained so heavily that it no longer performs the work they need. They might also be bypassing restrictions that exist for good reasons involving privacy, security, regulation or organizational risk. The existence of a workaround doesn't tell us which case we're looking at. It tells us where to look.

Find out what people were trying to accomplish, what the approved system prevented, and why the restriction existed. Maybe the guardrail changes. Maybe the workflow changes. Maybe the restriction remains and the organization provides a safer way to accomplish the legitimate part of the task. Alignment happens in that investigation too.

This is what deployment adds that a specification can't fully provide in advance. It exposes the system to more situations than its designers could enumerate. That doesn't make deployment inherently wiser than training or evaluation. Real-world feedback is noisy. Users can be mistaken. Developers can misinterpret incidents. A behavior that produces complaints may still be preferable to one that produces immediate satisfaction. Feedback gives us more observations, not automatic conclusions.

Suppose an AI system produces an answer that causes a problem. Sometimes a narrow patch is appropriate, but the incident may reveal a broader distinction the system or safeguard wasn't making. What information was available? What did the system appear to infer? Which part of the response created the risk? Was the failure in the underlying model, the surrounding instructions, the safety layer, the interface, the information available to the user, or some interaction among them? Would a superficially similar request be safe in another context?

Now one incident can improve more than one test case.

This is where I still find the idea of corrigibility useful, although I'd apply it to more than the model. Can failures be detected and reported? Can developers reproduce them? Can the behavior be changed without breaking unrelated capabilities? Can the correction itself be evaluated? Can the organization discover that yesterday's correction created tomorrow's problem?

A model that can technically be updated isn't very corrigible if the organization operating it refuses to acknowledge failures. A careful organization can't correct much if the system gives it no useful evidence about what happened. Neither can learn effectively if every unusual outcome is compressed immediately into either "the AI failed" or "the user used it wrong." The disagreement has to remain visible long enough to investigate.

Evaluations therefore continue to matter after deployment. Pre-deployment evaluations establish baselines and catch problems before users encounter them. Deployment produces new cases, some of those cases become evaluations, and changes are tested against both the new failures and the old behavior we don't want to lose. Then the updated system returns to use and encounters circumstances we still didn't anticipate.

That isn't evidence that alignment has failed to converge. It's what operating a complicated technology in a changing environment looks like.

Security already works this way. A secure system isn't one that passed an audit five years ago, but discovering a new vulnerability doesn't mean the original audit was worthless. The audit reduced uncertainty at one point in time. The vulnerability provided new information. The patch changed the system, and the changed system now has to be examined again. Nobody expects this process to end while the underlying technology and environment continue changing.

AI alignment may have a similar operational character. That doesn't mean every safety decision should remain permanently open. We don't need to reconsider from first principles every morning whether exposing private information is acceptable. What may change is our understanding of where that principle applies, how reliably we can identify the relevant information, and what mechanisms enforce the boundary without preventing legitimate uses. The principle can remain stable while its implementation changes.

This distinction matters because otherwise "alignment as practice" can become an excuse for never committing to anything. Permanent uncertainty isn't alignment, and neither is permanent revision. We need some things settled enough that people can depend on them while retaining some path by which relevant new evidence can reach the implementation.

That path includes users, researchers, evaluators, engineers, domain experts and people affected by the system's mistakes. It can include the model's own explanations of what happened, provided we remember that those explanations are another source of evidence rather than privileged testimony from inside the machine. Sometimes a model's explanation will help identify a useful distinction. Sometimes it will be a plausible story generated after the fact. We need other observations against which to compare it.

Transparency can be understood the same way. We may not have a complete human-readable narrative corresponding to the computation that produced an answer, but we can still know which model version produced it, which instructions and tools were available, what context can be reproduced, which safeguard intervened and whether behavior changes when we vary relevant parts of the input. None of that gives us complete understanding. It gives us somewhere to begin when something unexpected happens.

That is the operational center of alignment as practice for me: build safeguards for failures we already understand, evaluate them before deployment, observe what happens in use, preserve reports that don't fit our expectations, investigate rather than merely classify, and turn what we learn into new tests, better models, different safeguards or, occasionally, the conclusion that the original behavior was appropriate after all.

Then repeat.

Some of this work will reduce restrictions. Some of it will add them. That's another reason I no longer think of learning and constraint as opposing directions. Learning can reveal that a boundary was unnecessary, and it can reveal that a boundary wasn't strong enough. The direction of the update depends on what happened.

That leaves us with a less dramatic definition of alignment than the one I started with. An aligned system isn't necessarily one that has learned the spirit beneath every rule. I'm not sure we know how to establish that. A more useful target is a system whose behavior remains subject to evidence: known risks can be constrained, unknown failures can become visible, corrections can be made, corrections can themselves be questioned, and people affected by the system have some route through which what they encounter can reach the people and processes capable of changing it.

None of that guarantees safety, and it doesn't guarantee that every update improves the system.

It does keep deployment from becoming the point where learning stops.

Alignment isn't complete when the tests turn green. That's when we find out what the tests didn't contain.