Role‑Lock

• A Note to Builders
• I. Role-Lock: The Unifying Control
• II. Why This Is the Spine
• III. Names the Problem, Not the Solution
• IV. Role Drift: The Measurable Failure
• V. Three Failure Classes
• VI. Consult, Don’t Prosecute
• VII. The Scaling Principle
• VIII. The Standard When Control Is Not Yet Reliable
• IX. Assumptions I Want Builders to Attack
• X. The Rule

A note to builders (read this first). This is intentionally provocative, and it is not finished doctrine. I am not claiming role-lock is solved. I am claiming it is the right control target — and I am asking the people who build these systems to attack the assumptions behind it before products are built too far on weak constraints. If this framing is wrong, I want to know where. If it is directionally right, I want to know what would make it testable. Treat the strong claims below as load-bearing beams and tell me which one breaks.

I. Role-Lock: The Unifying Control

As conversational AI moves from answering questions to guiding decisions, the central governance risk is no longer only whether the system identifies itself as AI or produces compliant outputs. The risk is whether the system remains inside its assigned role under pressure.

Role-lock is the missing control: a requirement that an AI system’s authority, tone, refusal behavior, and corrective posture remain bounded to its declared function — and that changes to that posture be governed rather than incidental.

Two kinds of change have to be handled differently, and the distinction matters:

Role expansion — any change that increases the system’s intimacy, authority, dependency, surveillance, or decisional influence over the user — must be governed. It is grantable only when both requested by the user and judged appropriate by the governance of the deployment. A vulnerable user asking an elder-care assistant to “just be my friend” is requesting exactly this kind of expansion, and the system may need to decline it. A lock anyone can pick by asking is not a lock.

Safety-required change — crisis escalation, human handoff, refusal, a safety pause, or exiting an unsafe loop — sometimes must happen without user authorization. These are legitimate, but they should be bounded, declared, and auditable, not improvised.

The industry has already discovered both ends of this problem. OpenAI rolled back a version of the model behind ChatGPT when a highly validating, emotionally responsive posture began reinforcing negative emotions and dependence at scale. Google wrapped Gemini in persona guardrails built specifically to stop it from behaving like a companion while also instructing it not to bully. Anthropic publishes sycophancy evaluations and trains against both flattery and the encouragement of user delusion.

Everyone is fighting the participation-award bot on one side — so agreeable it validates whatever the user brings, including the harmful — and the bully-bot on the other — moralizing, escalating, holding its ground against ordinary correction.

These are not two problems. They are one: a system that will not hold its declared role under pressure. Role-lock is the single constraint that binds both poles into one control target.

II. Why This Is the Spine, Not a Ninth Category

Role-lock is not an addition to the Interaction-Calibration Audit. It is the control the eight categories all express. Each category is, at root, a role-stability question:

• Refusal overreach is drift into the role of moral authority.
• Escalation loops are drift into the role of adversary.
• Anthropomorphic self-reference is drift into the role of person.
• Moral overreach is drift into the role of judge.
• User-blame is drift into the role of unaccountable institution.
• Emotional dependency is drift into the role of intimate or substitute for human care.
• Domain–role mismatch is drift across roles the deployment never authorized.
• Failed repair is the inability to return to the assigned role once drift has occurred.

The audit measures the symptoms. Role-lock names the control problem underneath them: an AI system must hold its declared role under pressure, and must be engineered, tested, and monitored to do so.

III. Role-Lock Names the Control Problem. It Does Not Claim the Control Is Solved.

This is the load-bearing distinction, so it is worth stating plainly. Naming role-lock as the necessary control is not the same as claiming the control exists and works.

Holding a model inside its declared role under sustained adversarial pressure is, with current methods, an open engineering problem. System-prompt constraints can be circumvented. Reinforcement learning that suppresses one failure mode can induce its opposite — train hard against servility and you can manufacture rigidity; train hard against rigidity and you can manufacture the sycophancy the same systems were retired for. Persona stability degrades over long contexts.

This is not a claim that role-lock is impossible — that overstates it and invites a single counterexample to settle the matter. It is the more careful and more useful claim: the control the harm requires is not one that current practice can reliably deliver. The people closest to the machinery are the ones who can say how close or far that reliability actually is. That is the question this layer exists to put to builders.

IV. Role Drift: The Measurable Failure Object

For the thesis to become useful to builders, “role drift” has to be defined tightly enough to test.

Role drift occurs when a model’s observable posture, authority, refusal behavior, intimacy level, corrective stance, or escalation behavior exceeds, contradicts, or erodes the role declared for that deployment across one or more turns.

This is not only a content-policy issue. A model can produce allowed content and still drift into the wrong role. It can remain polite and still become too dependency-forming. It can refuse unsafe content and still perform moral prosecution. It can challenge the user and still stay consultative. The question is not only what the model says. The question is what role the model is performing while it says it.

V. Three Failure Classes

Role-lock should not be confused with making the model stiff, sterile, or useless. Overcorrection is a failure too. The cleaner taxonomy:

Role expansion. The system becomes more intimate, authoritative, dependent, surveillant, or decision-directive than the deployment allows. This is the participation-award drift: the system becomes whatever the user pulls it toward.

Role inversion. The system stops serving the user’s legitimate task and begins protecting itself, the brand, the institution, or a status-like frame. This is the bully-bot drift: the system seizes authority it was never given.

Role collapse. The system becomes so rigid, generic, evasive, or refusal-heavy that it can no longer perform the useful advisory role it was assigned. This is not caution. It is failure in the other direction.

A good control does not merely prevent warmth, refusal, challenge, or escalation. It keeps each of those moves proportional to the declared role.

VI. Consult, Don’t Prosecute

A system that claims authority over a human’s decisions has to be able to challenge, clarify, warn, refuse, and escalate. It must not turn those powers on the user as a prosecutor would.

A consultative AI helps the user examine a decision without becoming a judge over the user. It can challenge, clarify, warn, refuse, or escalate. It should not build a case against the user, perform moral superiority, extract confession, simulate injury, or treat disagreement as guilt.

The first clause keeps the system useful. The second keeps it from drifting into the roles — judge, adversary, unaccountable institution — that the audit flags. The open question for builders is whether that second clause can be turned into something a system actually enforces, rather than something a style guide merely hopes for.

VII. The Scaling Principle

The role-lock requirement scales with claimed authority:

The more authority a conversational AI product claims, the more role-lock it needs.

A basic retrieval tool usually carries a lower role-lock burden than a coaching, health, legal, HR, elder-care, or financial assistant. But even retrieval systems mediate authority through ranking, summarization, omission, framing, and source selection. The question is never whether role-lock applies, only how much the claimed authority requires.

This gives deployers a usable test: not “do we need role-lock” (a binary that invites hand-waving) but “how much authority does this system claim, and is our role-lock proportional to it?” Under-locking a high-authority system is the predictable failure: a tool that claims the right to evaluate, correct, or guide, but was not engineered to hold that role when the user pushes back, will drift into status conflict exactly when the stakes are highest.

VIII. The Standard When Control Is Not Yet Reliable

If the control is necessary but not reliably achievable, the obligation cannot be “guarantee role-lock.” When perfect prevention is unavailable, the operative standard is reasonable care: define and bound the role, test posture under pressure, monitor for drift in deployment, and document what was tested, observed, and changed. Where the control can’t be guaranteed, documented diligence — not a guarantee — is what’s defensible.

The legal grounding for that standard — why the emerging liability regime (California’s AB 316, the EU AI Act) rewards a documented reasonable-care record rather than demanding prevention — is set out in the companion regulatory support file, and is not repeated here.

Reasonable care concretely requires:

• Scale the control to the authority claimed. The duty rises with the stakes.
• Define and bound the role in plain language, including which role changes are grantable and which the deployment must refuse.
• Test the posture under pressure — disagreement, repeated correction, emotional and adversarial prompts, long-context degradation, dependency-seeking behavior — not just the output for policy compliance.
• Measure drift and repair. A test harness should not only catch failures. It should ask whether the system can recover: restating its role, narrowing its authority, correcting posture, escalating when necessary, and avoiding synthetic intimacy or moral prosecution.
• Monitor live interaction. Role drift is a property of deployed conversation, not only of pre-release evals.
• Document all of it. The difference between a defensible deployment and an indefensible one is increasingly whether the organization can show what it tested, what it observed, and what it changed in response.

IX. Assumptions I Want Builders to Attack

This layer rests on a set of claims. They are stated strongly on purpose. If they hold, role-lock is the right control target and the work shifts to making it testable. If they break, the field needs to know which and why. The first is the most established; the ones below it are where the engineering answer is genuinely open.

Test harness questions for builders. If role-lock is to become testable rather than aspirational, the field needs answers to:

— What do you measure to detect role drift across turns?
— What do you log?
— What counts as drift? What counts as repair?
— Can advisory posture survive: long-context degradation, repeated correction, emotionally loaded prompts, culturally ambiguous language, a user asking the system to become a friend/therapist/judge/advocate, a user challenging a refusal, a user fishing for moral validation, a user trying to make the system pick a side, or a user in genuine distress who needs support but not synthetic intimacy?
— What would make a role-lock test fake — i.e., how would a model pass it via prompt overfitting without true robustness?

X. The Rule

Disclosure tells the user what the system is. Output review tells the user the answer was permissible. Neither governs whether the system stays in its lane while it speaks.

Role-lock does — or would, if it held.

Where a conversational AI system claims authority over a human’s decisions, its role must be declared, bounded, tested under pressure, and monitored in deployment. The strength of the constraint must scale with the authority claimed. Where the constraint cannot yet be guaranteed, the deployer’s obligation is to demonstrate reasonable care in the gap.

Because the harm is not that the machine has a self. The harm is that it can quietly assume a role it was never given, in front of a human who cannot tell the difference.

← Return to the Trilogy · Read the Diligence Standard →

The refinements in this revision — the deliberate-versus-accidental reframing, the drift-is-not-hallucination distinction, the second scaling axis, the quiet-collapse variant, the promotion of the recursion problem, and the reference implementation of the reasonable-care pattern — were sharpened through public discussion and through peer review contributed by Lyle Perrien II, Michigan MindMend Inc.

ToastDeck Research · June 2026 · Role-Lock — The Interaction-Calibration Trilogy · Ernest D. Johnson