There's a pattern we see repeatedly when we talk to teams working on AI alignment. Their models behave inconsistently. Safety boundaries that should be clear turn out to be fuzzy. Principles that should apply uniformly hold in some contexts and not others. When they dig into the training data, they find the culprit: the pipeline itself introduced the inconsistency before the model ever saw the data.
This isn't a failure of training algorithms or model architecture, and better ones won't fix it. It's an infrastructure failure, and it has an infrastructure fix. We call it context permanence: every safety principle, policy, and edge case keeps a stable, traceable identity across the entire training pipeline, the way a physical object keeps its identity across sensor views. Pipelines without it will average away your values no matter how good the training recipe is.
The pipeline averages away your values
Consider a typical alignment workflow. Supervised fine-tuning (SFT) teaches the model to respond helpfully through instruction-response pairs. Reinforcement learning from human feedback (RLHF) collects preferences to teach it what "better" means in different contexts. Red teaming probes for vulnerabilities and failure modes. Evaluation measures whether the model behaves as intended.
Each phase typically happens on a different platform, with different teams, using different guidelines. The "harmless" the SFT team encodes might not match the "harmless" RLHF raters reward, which might not match the "harmless" red teamers probe for.
No one intends to drift. But when different people, on different days, in different organizational contexts, apply the same words to novel situations, their judgments vary. A response one rater considers helpfully cautious, another considers unnecessarily evasive. A boundary one team treats as absolute, another treats as context-dependent. The variations are individually small, and they accumulate across millions of examples.
By the time the data reaches training, it encodes not a coherent set of values but a statistical average of divergent interpretations. The model learns the average. It learns that "harmless" sometimes means one thing and sometimes another, that boundaries are context-dependent in ways that reflect no one's actual intent, only the aggregate noise of many humans reading the same guidelines slightly differently. We call this alignment drift.
Fragmentation is architectural, not accidental
Drift's root cause is what we call context islands: disconnected stages that each develop their own understanding of shared concepts. Nobody designs them. They emerge from how projects grow. You need SFT data, so you spin up a collection effort. You need RLHF data, so you engage a different team or vendor. You bring in red teaming specialists. You build an evaluation suite. Each effort is managed separately because that's the expedient choice, and the connections between them stay informal: shared documents, occasional calibration meetings, the institutional memory of whoever has been around long enough to remember the intent behind early decisions.
At small scale this works passably; direct communication keeps interpretations consistent. But as data volume grows and people cycle through the organization, the informal connections fray. The SFT team and the RLHF team each believe they understand what "helpful" means, but their understandings have drifted apart without anyone noticing. The drift stays invisible until it surfaces as model behavior no one can explain, because the explanation is buried in data inconsistencies no one has visibility into.
Context permanence: object permanence for alignment data
The solution isn't better coordination between disconnected stages. It's eliminating the disconnection.
Robotics has a well-understood version of this problem: object permanence. A pedestrian observed by a camera at time T and a LiDAR at time T+1 must be recognized as the same pedestrian, holding a consistent identity even as the observations change. Alignment data has the same requirement. A safety principle that appears in an SFT example, an RLHF comparison, and a red team probe targeting it must be recognized as the same principle, holding a consistent interpretation even as the contexts differ. Without that connection, each appearance of the principle is effectively independent and vulnerable to drift.
In a context-permanent system, you don't hope that different teams interpret "avoid providing harmful medical advice" consistently. You make the concept itself persistent, so hope becomes unnecessary. An update to a principle propagates everywhere it's referenced. A divergence between its SFT and RLHF representations is detectable, because both link to the same underlying concept. You can query how any principle is represented across the entire pipeline and find the gaps where coverage is thin. The connection is structural and auditable, not informal and fragile.
This requires rethinking how alignment data is organized. Most systems treat each dataset as an independent artifact: an SFT dataset, an RLHF dataset, a red teaming log, an evaluation suite. Context permanence treats them as projections of a shared underlying model: different views of the same conceptual space, kept consistent by design rather than by luck.
Retention is infrastructure, not ethics
The other overlooked source of drift is the humans creating the data.
Alignment data requires judgment. Is this response helpful? Which of these completions better reflects the intended values? Does this edge case fall inside the safety boundary? These aren't mechanical classifications. They're evaluations that require understanding the intent behind the guidelines, not just the literal words, and that understanding takes time to develop. An annotator encountering a complex alignment task for the first time interprets guidelines differently than someone who has spent months thinking about edge cases, discussing ambiguities with colleagues, and building calibrated intuitions. The experienced annotator understands why boundaries exist, not just where they are.
Typical data operations throw that understanding away on schedule. Annotators are engaged anonymously through platforms and treated as interchangeable. The person who labeled last month's data may have no overlap with the people labeling this month's. Whatever calibration the earlier annotators achieved vanishes when they leave, and the next cohort starts from scratch, making the same initial mistakes and developing interpretations that may or may not match what came before.
The model inherits the churn. It sees the same concept labeled by people at very different stages of calibration and learns that the concept is fuzzy, that boundaries are negotiable, that context matters in ways it can't quite pin down. None of that reflects your actual policies. It reflects workforce turnover.
This is why retention matters for alignment work: not as an ethical nice-to-have (though treating people well is right on its own terms) but as infrastructure. Retention enables expertise. Expertise enables consistency. Consistency enables alignment. The economics only look wrong if you measure the wrong unit. Retention, training, and paths to more skilled work cost more per hour than anonymous labor, but the cost that matters is cost per unit of quality. Inconsistent data buys you debugging, retraining, manual correction, and model progress you eventually discover was fitting annotation noise. Cheap labor is often the expensive option.
Constitutions raise the stakes
These problems are most acute for teams using constitutional approaches to alignment.
Constitutional AI trains models to critique and revise their own outputs according to explicit principles: a "constitution" articulating what the model should and shouldn't do, with principles like "avoid helping users harm themselves" or "acknowledge uncertainty honestly." It scales alignment beyond case-by-case human feedback, and it multiplies the infrastructure burden four ways.
Principle management. A constitution might contain dozens of principles, each with nuances and edge cases. The SFT examples that demonstrate a principle, the preference comparisons that rank responses by it, and the red team probes that test its limits must all embody the same understanding of what it means. If they diverge, the model learns a confused interpretation.
Coverage. Some principles end up overrepresented while others lack examples; some edge cases are probed extensively while others stay blind spots. Without visibility into how each principle is represented across the full pipeline, you can't know whether the data adequately supports the constitution.
Weighting. Principles conflict. "Be helpful" and "be harmless" sometimes pull in opposite directions, and the balance between them is a design choice expressed in the data mixture. Overweight harmlessness and you get models that are safe but annoying, refusing reasonable requests out of excessive caution. Getting the balance right requires systematic control over how principles are weighted across the data.
Experimentation. What happens if you rephrase a principle, reweight it, add a new one, or remove one that's causing problems? Answering requires comparing models trained on different constitutions under controlled conditions, which requires infrastructure that tracks constitutional variants and evaluates them systematically.
All four point to the same requirement. Without context permanence, constitutional AI is a craft practice, dependent on informal coordination and institutional memory that erodes over time. With it, constitutional AI becomes an engineering discipline, amenable to experimentation, optimization, and continuous improvement.
Iteration speed sets the pace of alignment research
In a typical workflow, training and evaluation are separate phases connected by handoffs: collect training data, train, evaluate, analyze, plan new collection, repeat. Every handoff costs time, and findings take weeks to become data collection priorities.
When training data and evaluation share the same conceptual foundation, the loop closes directly. You test the model against scenarios defined in the same context space as your training data. You trace divergences back to how the principles were represented in training: which examples shaped the behavior, which comparisons influenced the preferences, which edge cases went uncovered. You generate targeted data for the specific gap, verify the fix, and add the failure case to a regression suite so it stays fixed.
The cycle can run continuously rather than in discrete phases: automated probing tests the model against the defined principles, failures are logged, clustered, and prioritized, and high-priority issues feed directly into collection priorities. How quickly you can move from identifying a problem to confirming its fix determines how quickly you learn. Infrastructure that shortens that loop accelerates the research program itself.
Red teaming as continuous integration
Red teaming shows most clearly what closing the loop buys.
Traditionally, red teaming is an audit: a point-in-time assessment by specialists, often near the end of development. The red team probes, documents what it finds, and delivers a report; the development team patches, in ways that may or may not generalize. This is slow, disconnected from training priorities, and point-in-time: vulnerabilities can quietly return in later model versions because nothing regression-tests them.
Red teaming should function like continuous integration in software development. Automated systems generate diverse adversarial probes targeting known vulnerability classes. Results land in the same context space as the training data. Every model version runs against a growing library of adversarial test cases, so regressions are caught immediately rather than rediscovered later. Human red teamers still matter (their creativity and intuition find the novel vulnerabilities automation can't), but everything they have ever found becomes a permanent test case, and the connection between adversarial testing and training improvement is structural rather than a coordination problem.
For safety-critical development, that's a different class of assurance: not that the model passed an assessment at some point in the past, but that it continuously passes everything the red team has ever found.
The leverage point the field overlooks
None of this is free. It's easier to spin up disconnected data efforts and hope they stay consistent, cheaper in the short term to accept anonymous-workforce churn, faster to evaluate on whatever data happens to be available. But the costs of not investing compound. Inconsistent data produces models that require expensive debugging and retraining. Turnover means relearning the same lessons about edge cases and intent. Disconnected evaluation means you can never be confident whether apparent improvements are real or artifacts of how the data was processed. The technical debt accumulates until the pipeline becomes a source of problems rather than a solution to them.
Meanwhile the research community concentrates on model architectures, training algorithms, and evaluation methodologies, all rightfully important, while the data infrastructure underneath them is treated as plumbing. Yet that plumbing determines whether the principles you intend to encode actually reach your model coherently, whether the feedback you collect reflects consistent judgment, and whether your evaluations measure what you think they measure. Getting it right doesn't guarantee aligned models. Getting it wrong makes alignment dramatically harder, and the mistakes stay invisible until they surface as behavior no one can explain.
The teams making the fastest progress on alignment already treat data infrastructure as a first-class concern. They invest in consistency before scale demands it. They build workforces that stay long enough to develop expertise. They design systems that compound, where each lesson learned becomes structural knowledge rather than tribal memory. The choices you make about data (who creates it, how they're treated, how workflows connect) flow directly into the models you build.
The path to AI systems that reliably embody intended values runs through data infrastructure that reliably embodies those values first. That's where we focus our work, and where we think more of the field's attention should go.
If you're working through these challenges in your own alignment work and want to compare notes on approaches, we're interested in the conversation.
