How do you triage persona slip versus hard-rule violations in long chats?

## Two failures, one cause Instruction drift produces two visibly different outcomes. In one, the assistant is still doing its job but stops being *itself*: the terse expert becomes chatty, the second-person coaching voice reverts to neutral explanation, the required greeting disappears. In the other, a rule with teeth breaks: a prohibited recommendation is given, a mandated disclaimer is missing, the JSON the downstream service parses arrives as prose. Same mechanism — a standing instruction losing salience in a long window — completely different consequences. ## Classify by blast radius, not by how the rule was written The useful axis is what happens on a single violation: - **Cosmetic** — a user notices the assistant sounded different. Cost: a small quality ding, aggregated over many sessions. - **Functional** — something downstream breaks: a parse fails, a workflow stalls, a retry burns budget. Cost: real but bounded and usually detectable. - **Consequential** — regulatory, safety or trust damage: prohibited advice, leaked internal instructions, a missing required disclosure. Cost: unbounded, and one occurrence is enough. Every line of a system prompt should carry that label. In practice most lines are cosmetic, a handful are functional, and one or two are consequential — and teams are routinely surprised by which is which when they do the exercise. ## What each class deserves **Cosmetic rules** get a *decay budget*. Pick the depth that covers most real sessions, pick an adherence floor, measure it with multi-turn scripts, and accept anything above the floor. A short late reminder is fair game; a per-turn essay about voice is not. Over-anchoring tone has a real failure mode: the model starts performing the persona rather than helping, and answers get worse in exactly the sessions the reminder was meant to protect. **Functional rules** should usually move out of the prompt into structure. Where the constraint is shape, use constrained or schema-validated output and validate on receipt; where it is presence of a token, check and repair. Prompt instructions remain useful as a hint that improves first-pass success and reduces retries, but the guarantee comes from the checker. **Consequential rules** must not be enforced by adherence at all. A prohibition that only holds while the model is paying attention is not a control. Options, roughly in order of strength: remove the capability (never wire the tool, never expose the data); gate the output behind a deterministic classifier or rule engine that can block; require human approval for the risky class; and only then, prompt language as defence in depth. The honest framing for a review board is that a system prompt shifts probabilities and a control does not. ## The cost side Re-anchoring is not free, and the bill scales with traffic and conversation length: every reminded rule is tokens on every turn of every session, forever. Fifty tokens per turn across a sixty-turn median session is three thousand tokens of pure overhead per conversation. That is a budget worth spending on the two rules that matter and worth refusing for the twelve that do not. The same logic caps the sticky reminder block: additions must displace something, or produce eval evidence that they buy adherence where it was falling. ## Making the tradeoff visible The deliverable at this level is not a prompt tweak, it is a policy: a table of standing constraints, each with a class, an owner, an enforcement mechanism, and — for the ones left to the prompt — a measured adherence floor at a stated conversation depth. It makes three otherwise invisible things arguable: which rules we are choosing to leave probabilistic, how much per-turn token overhead we are buying, and at what conversation depth we are effectively out of warranty. Without it, drift gets addressed by whoever saw the last bad transcript, the reminder block accretes, and a compliance requirement quietly sits in a paragraph that the model reads less carefully every turn. ## Contested ground Where the line falls is genuinely debated. Teams shipping consumer assistants often argue persona *is* the product and deserves functional-grade treatment; teams in regulated domains push almost everything toward deterministic gates and accept a blander assistant. Both are defensible. What is not defensible is having no classification at all and discovering the class of a rule from an incident report.