Persona fractures first on failure and refusal

What it is

Success lines are easy to keep in one mouth. Didn't catch that, cannot do that, must refuse by policy — those lines often change author, and persona splits on the turn the user weights most. The last turn was “living-room light is off”; the next is engineer-register “this feature is temporarily unavailable, please try again later,” or counsel-register “we are unable to process that request.” The split is not “too much personality.” It is failure and refusal not using the same wording, length, and address.

Why it happens

Success paths are written by the persona or copy team. No-match, backend failure, policy refusal, and out-of-scope usually come from engineering defaults, legal templates, or NLU fallbacks — more of them, more owners. Listeners overweight negative events: one cold refusal covers twenty warm successes, because the failure turn is where they decide whether the thing is still trustworthy. Refusal is also where a capability boundary is spoken — a jokey refusal reads as mockery, a telegram refusal as a different product. Both can say “cannot” clearly, without charm to hide the limit and without swapping speaker.

Failure lines also get authored as “system messages”: codes, English exception names, no address, length suddenly doubled. All three knobs jump at once, so a subject change is guaranteed. Safety refusals may be shorter and flatter on purpose — a second register. The register still has to be stable inside itself, and the switch from everyday to safety has to be expected, not a mix of one cheeky refusal and one public-notice refusal.

Studying it

Collect every fallback, error, rejection, and out-of-scope line. Compare them to success lines with stylometry (lexicon, length, address) and with human “still the same person?” ratings. In a user study: a few success turns, then one failure or refusal; measure continuity of the agent and trust afterwards. In logs, search complaints about “tone” or “it suddenly,” and see which dialogue acts they sit on — usually not the greeting.

Do not review only the hello set. Hellos are where the most persona effort went and the least fracture lives; sampling them yields a false negative that “the persona is stable.”

Where it stops holding

Safety refusals on self-harm or illegal requests should be flat, short, and joke-free; that is a register switch, not a fracture — write it down, and send every safety refusal through that register. Beep-only IVR has no persona to split. A brand that wants a harder voice on refusal can have it, if the hardness is even. Using a chilly system message to “be honest about limits” is achieving candor by fracturing — candor can be spoken in the original mouth.

Applying it

• Start persona QA on the failure set: no-match, API failure, policy refuse, “I don't do that.” Run each through the same three columns as success. Read a success line then the failure; listen for a speaker change.
• Build a separate register for safety and legal: shorter, drop pet names, list banned jokes. Do not mix one suddenly colloquial refusal back into that register.
• Ban internal codes, English exception names, and subjectless sentences on failure unless that is the written contract of the safety register.
• How to check: record ten success → failure pairs. If people who did not write them say “someone else” on the failure, edit the failure against the three columns. Do not sand down an already-stable success line to “meet in the middle.”

Related

• Same group: M2.10.1 Persona is the joint of wording, sentence length, and forms of address · M2.10.3 First person invites inferences of capability and blame
• Nearby: M2.05 Persona · M2.04 Error-recovery wording · M4.11 Gender and stereotypes in voice assistants
• Search terms: persona fracture · error register · refusal wording