Nadia is a terminologist at a language-service provider (an LSP, a company that sells translation and localization), and on a wet Thursday she is staring at two renderings of the same German source clause, produced by the same large language model (an LLM, a general text-prediction system that drafts translations), ten minutes apart, and she cannot stop thinking about how plausible they both sound. The source is a sentence from a cardiology device's instructions for use. The first rendering, produced from a bare "translate this into US English" prompt, calls a particular event a "heart attack." It reads beautifully. It is wrong, or at least dangerously loose, because the source said "myocardial infarction" in a regulated clinical register and the label has to say exactly that, not the waiting-room paraphrase. The second rendering came after a colleague added one line to the top of the prompt: "You are a clinical translator specializing in cardiology device labelling; use the formal medical register and the approved glossary." That version says "myocardial infarction." It also, two sentences later, invented a contraindication that the source never contained, stated in flawless clinical prose, with the calm authority of a cardiologist who has seen a thousand of these. Nadia has worked in localization long enough to know which of those two errors scares her more. The loose paraphrase is the kind a tired reviewer catches. The confident, expert-sounding fabrication, delivered in exactly the voice she just asked the engine to adopt, is the one that gets skimmed past and shipped. This lesson is about that exact tradeoff: what it really means to tell an engine to "reason like a domain specialist," when that instruction genuinely raises quality, when it is pure theater, and how to combine a persona with the grounding and glossary controls that keep the new, more authoritative voice from becoming a more authoritative liar.

What a Persona and a Domain Constraint Actually Are

Three words in this lesson carry the whole argument, so define them precisely before doing anything with them. A persona (also called a role instruction) is a sentence you give the model that tells it who to be: "You are a sworn legal translator," "You are a clinical pharmacist translating drug labelling," "You are a financial reporting specialist." A domain constraint is the narrowing of the subject matter the model should reason inside: cardiology, contract law, IFRS financial reporting, automotive repair, each a field with its own settled vocabulary, conventions, and what counts as a correct rendering. A register is the level of formality and the conventionalized style the content demands: the clipped imperative of a safety warning, the hedged caution of a patient leaflet, the rigid formula of an indemnity clause, the plain numbered prose of an audit note. A constraint, in the sense this lesson uses throughout, is any instruction that narrows what the model is allowed to produce, as opposed to merely suggesting what it might produce.

Put those together and a persona-and-domain instruction is a single move: you prepend to the translation task a statement of who the model is, what field it is working in, and what register the output must hold. "You are a translator specializing in regulated pharmaceutical labelling. You work in the clinical-formal register. Render the source into US English using the conventions and terminology of pharmaceutical instructions for use." That instruction does not change the source text and it does not change the model's weights. What it changes is the slice of the model's enormous training distribution that the next words are most likely to be drawn from. The previous lesson in this chapter taught chain-of-thought (CoT), making the model show its reasoning before its answer so you can audit the logic. Persona and domain constraint operate on a different lever: not the visibility of the reasoning, but the neighborhood the reasoning happens in.

It helps to be very concrete about the mechanism, because the entire question of "does this help or is it theater" turns on understanding what the instruction physically does. An LLM predicts the next token (the next chunk of text) from everything before it. A medical persona at the top of the prompt raises the probability that the tokens it predicts next come from the regions of its training where medical text lives: clinical terminology, formal register, the conventional phrasings of a drug label. It is, mechanically, a steering instruction on a probability distribution. It does not give the model new knowledge it did not have, and it does not install a rule engine that forbids errors. It tilts the dice. Everything useful about personas, and everything dangerous about them, follows from that one fact: a persona is a strong nudge on probabilities, not a guarantee about outputs.

A persona does not teach the model anything or forbid it anything. It tilts the probability distribution toward the region of training where the named specialist's language lives. It is a steering instruction, not a rule engine, and it can steer you toward a fluent expert voice that is confidently wrong as easily as toward a correct one.

Why the Instruction Changes the Output at All

Skeptics, rightly, ask whether telling a model "you are an expert" does anything beyond flattering it, and the honest answer is that it does, for a specific and limited reason. The model has, in its training, seen vast amounts of cardiology text, contract text, financial text, each with its own consistent vocabulary, register, and phrasing patterns. Without a steer, a translation prompt sits in a generic middle of the distribution, where "myocardial infarction" and "heart attack" are both reachable and the more common, more colloquial option often wins because it appeared more often across the whole internet-scale corpus. The persona instruction shifts the starting point. By naming cardiology and the clinical register, you move the model toward the region where "myocardial infarction" is the locally dominant phrasing, because in actual cardiology labelling that is what people write.

So the change is real, and it is most real exactly where a domain has a settled register that differs from everyday language. That is the legitimate core of the technique. The danger arrives in the same motion, because the persona shifts the model toward sounding like the specialist regardless of whether it has the specialist's actual knowledge of this specific source. It now produces clinical-sounding prose with clinical-sounding confidence, and a clinical-sounding confident error is harder to catch than a colloquial one, not easier. The instruction that improves the register can simultaneously deepen the camouflage on a mistranslation. Holding both of those truths at once is the whole skill of this lesson.

When a Persona Genuinely Helps

There is a real, defensible set of cases where adding a persona and domain constraint measurably improves output, and naming them precisely is more useful than a blanket "personas are good." The common thread in every case that works is the same: the win comes from steering the model into a register or a vocabulary that differs from generic, everyday language, in a way the source itself does not fully signal.

Register selection. This is the strongest and most reliable benefit. When a domain's conventional style differs sharply from common usage, the persona pulls the model toward the conventional style. A legal persona pulls toward the formulaic, deliberately archaic phrasing of contract language ("the party of the first part," "hereinafter," "shall indemnify and hold harmless") that a generic translation would smooth into plain modern prose, destroying the legal force. A clinical persona pulls toward the cautious, hedged, precisely-qualified register of patient-facing medical text, where "may cause" and "can cause" and "is associated with" are not interchangeable. A financial persona pulls toward the rigid conventions of reporting standards. In each case, the source is written in that register and the correct target must be too, and the persona is the cheapest way to move the model's default style toward it.

Terminology disambiguation by domain. Many words mean different things in different fields, and the domain constraint resolves the ambiguity the way the field does. The German "Anlage" can be an attachment, an investment, a plant or facility, or an enclosure, depending on whether you are in legal, financial, engineering, or general correspondence. A financial-domain persona makes "investment" or "asset" the more probable reading; a legal-domain persona makes "enclosure" or "exhibit" more probable. The persona does not guarantee the right pick, but it loads the dice toward the field's conventional sense, which on domain-specific text is more often right than the generic default.

Convention adherence. Fields have phrasing conventions that are not strictly terminology but are still expected: how a pharmaceutical leaflet structures a warning, how a contract numbers and cross-references its clauses, how a financial note conventionally phrases a restatement. A persona steers the model toward producing these conventional shapes, which reduces the post-editing (the human correction of machine output) needed to bring the draft up to the register a reviewer expects. The persona is not adding accuracy here so much as reducing the gap between the draft's style and the domain's house style, which is a genuine and measurable saving.

A persona earns its place when the domain's register, terminology sense, or phrasing conventions differ from everyday language in a way the source does not fully flag. Its job is to move the model's default style toward the field's house style. That is a real saving on style, and it is the legitimate reason to use the technique at all.

The Cardiology Example, Where It Works

Return to Nadia's first rendering, the one that said "heart attack." That is precisely the failure a persona fixes well, because the source said "myocardial infarction" and the engine, left in its generic default, reached for the more common colloquial phrase. A cardiology persona ("You are a clinical translator specializing in cardiology device labelling; render into the formal clinical register used in instructions for use") moves the model toward the region of its training where "myocardial infarction" is the dominant phrasing, and the colloquial smoothing stops. The win is real and it is repeatable across a whole file: every place the source uses a precise clinical term, the persona makes the precise target more probable than the colloquial one. This is the technique doing exactly the job it is good at, raising the register and the terminological precision to match the source's domain.

Notice what the win is and is not. The persona made the register correct. It did not verify that "myocardial infarction" is the client's approved term (a glossary does that), and it did not stop the engine from inventing a contraindication two sentences later (nothing in the persona addresses fabrication). The persona solved a style-and-register problem cleanly and left the accuracy problems exactly where they were. That separation, persona handles register, other controls handle accuracy, is the design principle the rest of this lesson builds on.

When a Persona Is Theater

Now the harder half, because the technique is wildly over-prescribed, and a great deal of "prompt engineering" advice treats "you are an expert" as a magic phrase that improves everything. It does not, and knowing the cases where a persona does nothing useful, or actively harms, is what separates someone applying a discipline from someone repeating a superstition.

Persona theater happens when the persona has no register to select. If the source is plain, register-neutral prose, a marketing tagline, a UI string, a general informational sentence, there is no specialist register for the persona to pull toward, so the instruction does nothing except possibly nudge the model toward unnecessarily formal or jargon-heavy phrasing the content did not want. Telling the model "you are a senior translator with twenty years of experience" before translating "Welcome to your account" is pure theater. The seniority claim cannot improve a sentence that has no domain. Worse, the inflated persona can make the output stiffer than the friendly UI register the string actually needed.

Persona theater happens when the win you need is accuracy, not register, and you reach for a persona instead of a control that addresses accuracy. This is the most expensive form of theater, because it feels like you did something safety-relevant when you did not. If the real risk on a file is a flipped dosage, a dropped negation, an invented contraindication, or a drifted approved term, a persona does not reduce any of those risks. A medical persona does not make the model better at preserving the negation in "patients should not exceed two doses." It makes the model better at sounding like a clinician while it possibly drops the "not." Reaching for the persona because the content is high-stakes, and then feeling protected, is the trap: you have changed the voice, not the verification, and the voice was never the thing that was going to hurt a patient.

Persona theater happens when the persona substitutes for grounding. "You are an expert in our product's terminology" does not give the model your product's terminology; it gives the model permission to sound like it knows your terminology while drawing on whatever generic terms its training prefers. The persona is a steer over the model's existing knowledge, and if the knowledge you need is your client's specific approved terms, your translation memory (TM, the database of past approved translations), or your style guide, the persona cannot supply it. Only grounding, feeding the actual approved material into the prompt, can. A persona offered as a substitute for grounding is theater dressed as expertise, and it is dangerous precisely because it produces confident, plausible, specific-sounding output drawn from the wrong source.

A persona is theater when there is no specialist register to select, when the real risk is accuracy rather than style, or when it is standing in for grounding it cannot provide. In all three cases it changes how the output sounds without changing whether the output is right, and on high-stakes content that gap is where the liability lives.

A Test for Theater Versus Substance

Here is a single question that sorts almost every case: what would change in the output if I removed the persona line? If the answer is "the register would slip from the domain's conventional style toward generic phrasing," the persona is doing real work, keep it. If the answer is "nothing meaningful, the content has no specialist register," it is theater, drop it. And if the answer is "I am hoping it would be more accurate," that is the dangerous middle, the persona will not deliver accuracy and you have mistaken a style control for a safety control, so replace the hope with an actual accuracy control: grounding, a glossary, a verification step, a flag instruction. The persona's job is register. If you need something other than register, the persona is the wrong tool, no matter how high the stakes, and high stakes are exactly when reaching for the wrong tool because it feels reassuring is most costly.

The Risk That Theater Hides: A Confident, Wrong Expert Voice

The central danger of personas deserves its own treatment, because it is subtle and it inverts the intuition that makes the technique attractive. The whole appeal of a persona is that the output sounds more authoritative, more like a real specialist wrote it. That is also exactly the problem, because authority of voice and accuracy of content are independent variables, and a persona raises the first without touching the second.

Recall the program's spine: machine output is fluent first and accurate second, and the fluent error is the dangerous one because it does not trip your eye. A persona makes the output not just fluent but fluent in the specialist's voice, which raises the camouflage another notch. A generic mistranslation of a medical sentence at least sometimes reads slightly off, a little too plain, a little too vague, and that wrongness is a faint signal a reviewer might catch. The same mistranslation rendered by a "clinical specialist" persona reads exactly like correct clinical text: the right register, the right cadence, the right confident phrasing. It has acquired the surface markers of expertise without the substance, and those surface markers are precisely what a reviewer uses as a quick proxy for trustworthiness. The persona has made the error better-disguised, not less likely.

This is why the medical-content error rates that anchor this whole program are so alarming in the persona context. Studies of LLM output on medical content found error rates around 59% on drug names, 60% on dates and times, and 66% on adverse events, every one delivered in grammatically perfect prose. A persona does nothing to lower those rates, and by tightening the clinical register it can make each of those errors read more like authoritative clinical writing. The contraindication Nadia's second rendering invented was not a vague hallucination; it was a fluent, well-formed, clinically-phrased contraindication, indistinguishable in style from a real one, because she had just asked the engine to write like a clinician and it obliged on the style while fabricating on the substance.

Authority of voice and accuracy of content are independent. A persona raises the first and leaves the second untouched, which means it improves the disguise on every error it does not prevent. The confident expert voice is not evidence of correctness; on machine output it is the most effective possible camouflage for a fabrication.

Why the Camouflage Defeats the Reviewer

Human reviewers, even skilled ones, lean on register as a heuristic for competence, because in human writing the two correlate: a person who writes in fluent clinical register usually does know the clinical content. That heuristic is reliable for humans and catastrophic for machine output, because the machine can produce the register without the knowledge. A post-editor scanning a file fast, under deadline, with MT (machine translation) having pre-populated every segment, is using exactly that heuristic to decide which segments to scrutinize and which to wave through. The persona-styled segments read as competent, so they get waved through, which means the persona has not only failed to prevent the error, it has actively routed the reviewer's attention away from it. This is the precise opposite of what you want a control to do.

The defense is to consciously refuse the register heuristic on machine output. A reviewer working with persona-styled MT has to internalize that the polished clinical voice is a property of the prompt, not evidence about the content, and check the substance, the numbers, the negations, the named conditions, the approved terms, with the same skepticism they would apply to clumsy output. The persona-styled file is not a lower-risk file because it reads better. If anything it is a higher-vigilance file, because the same errors are present and better hidden.

Combining Persona With Grounding and Glossary

The resolution to all of this is not to abandon personas; it is to use them for exactly what they do (register) and to pair them with the controls that do what they cannot (accuracy and terminology). A persona alone is a style control masquerading as a safety control. A persona combined with grounding and a glossary is a style control sitting on top of actual safety controls, which is the correct architecture.

Define the partners precisely. Grounding means feeding the model the actual approved material it must work from, the source segment, the relevant translation-memory matches, the style guide rules, retrieved and placed in the prompt, so the model answers from your linguistic assets rather than from its generic training. A glossary (or termbase) is the database of approved source-to-target term mappings the client requires used exactly, never paraphrased into a synonym the model prefers. Where the persona steers the model's general style, grounding and the glossary supply the specific, verified content and terms the persona cannot. They occupy different layers and they do not substitute for one another.

The combination works because each layer covers the other's exposure. The persona fixes the register so the output reads in the domain's conventional style. The glossary pins the exact approved terms so the persona's general steer cannot drift onto a fluent synonym; if the persona's tilt toward "myocardial infarction" happens to disagree with the client's approved term, the glossary, not the persona, wins. Grounding supplies the actual product names, the prior approved phrasings, the client-specific facts the persona could only guess at, so the model's specific claims come from your assets rather than its training. And a flag-uncertainty instruction catches the cases none of the three can resolve. The persona makes it sound right; the glossary and grounding make the named things actually right; the flagging surfaces what remains uncertain. That is a stack, not a single trick.

Use the persona for register and nothing else. Layer a glossary on top so approved terms beat the persona's fluent synonyms, ground the prompt on your real assets so specific claims come from your content not the model's training, and add a flag-uncertainty rule for what neither resolves. The persona makes it sound right; the other layers make it be right.

The Order of Authority When the Layers Disagree

The layers will sometimes pull in different directions, and a working practitioner has to know which wins, because an unresolved conflict is where the error sneaks back in. The order of authority is grounding and glossary first, persona second, and it has to be stated explicitly in the prompt, because the model does not automatically know that the approved term outranks its own domain-trained preference. If the cardiology persona's training makes "myocardial infarction" most probable but the client's glossary approves "heart attack" for a patient-facing leaflet aimed at a general audience, the glossary wins and the prompt must say so: "Where the approved glossary specifies a term, use it exactly, even if a more clinical or more common alternative seems preferable." Without that line, the persona's tilt can quietly override the glossary, which is term drift wearing an expert costume.

The same precedence applies to grounding. If a retrieved translation-memory match shows how this exact phrase was approved before, that approved rendering outranks whatever the persona's general style would generate fresh, and the prompt should instruct the model to prefer the grounded, previously-approved rendering. The persona's authority is over style in the absence of a specific instruction; it never outranks a specific approved term or a grounded prior decision. Getting this precedence wrong, letting the persona's confident general voice win over the client's specific approved content, reintroduces exactly the term drift and the off-source fabrication the other layers were added to prevent.

A Worked Example: Constraining the Engine to a Medical and a Legal Register

Make all of this concrete by building the combined instruction twice, once for medical content and once for legal, so the pattern is visible across two domains with very different registers. Each example is the kind of standing instruction you would attach to a recurring client-and-content-type scope, with the persona doing register work and the other layers doing accuracy work.

The Medical Version, Annotated

PERSONA AND DOMAIN. "You are a translator specializing in regulated cardiology device labelling, working from German (de-DE) into US English (en-US). Render the source in the formal clinical register used in patient-facing instructions for use: precise, cautious, and conventionally phrased. Do not simplify clinical terms into colloquial equivalents."

GLOSSARY (outranks the persona). "Use these approved equivalents exactly, every time, even if a more clinical or more common alternative seems preferable: 'Myokardinfarkt' = 'myocardial infarction'; 'Herzinsuffizienz' = 'heart failure' (never 'cardiac insufficiency'); 'Verschluss' = 'occlusion'. For any term not listed, use the standard cardiology-labelling equivalent; if you are unsure of the standard term, flag it rather than guessing."

GROUNDING. "Base every specific claim, condition, contraindication, dose, and warning only on the source segment provided. Do not add any contraindication, side effect, dose, or instruction that is not explicitly in the source, even if it is clinically plausible or commonly true for this device class. Your clinical knowledge is for register and terminology, never for supplying content the source does not contain."

FIDELITY AND FLAGGING. "Preserve every negation, number, dose, unit, and frequency exactly. A dropped or added negation, or an altered number, is a Critical error. When the source is ambiguous or you cannot confirm a term, translate as faithfully as you can and add [FLAG: reason] immediately after the affected text."

Read what each block is doing. The persona block selects the clinical register and explicitly forbids the colloquial smoothing that produced "heart attack," which is the legitimate persona win. The glossary block then immediately subordinates the persona to the approved terms and resolves a real conflict in advance: note that "Herzinsuffizienz" maps to "heart failure" and bans "cardiac insufficiency," because a free clinical persona might well prefer the more Latinate form, and the client did not approve it. The grounding block is the one that addresses the actual danger, the invented contraindication, by stating in the bluntest terms that the model's clinical knowledge is licensed for register and terminology only and is explicitly forbidden from supplying content. That single sentence, "your clinical knowledge is for register and terminology, never for supplying content the source does not contain," is the keystone of the whole medical example, because it directly forecloses the failure mode that makes a medical persona dangerous. And the fidelity-and-flagging block catches the numbers, negations, and residual ambiguity that no amount of register steering touches.

The Legal Version, Annotated

PERSONA AND DOMAIN. "You are a legal translator specializing in commercial contracts, working from French (fr-FR) into US English (en-US). Render the source in the formal legal register: preserve the formulaic, deliberately precise phrasing of contract language, including conventional legal formulae. Do not modernize, simplify, or paraphrase legal phrasing into plain English; the exact wording carries legal force."

GLOSSARY (outranks the persona). "Use these approved equivalents exactly: 'résiliation' = 'termination' (never 'rescission' or 'cancellation', which carry different legal meanings); 'le cas échéant' = 'where applicable'; 'sous réserve de' = 'subject to'. For any term not listed, use the standard US commercial-contract equivalent; if a term has a meaning that turns on jurisdiction, flag it."

GROUNDING. "Translate only what the source clause states. Do not add, infer, or 'complete' any obligation, condition, warranty, indemnity, or carve-out that is not explicitly in the source, even if it is standard boilerplate for this kind of contract. Do not resolve an ambiguity in the source by choosing the more common drafting; preserve the ambiguity and flag it."

FIDELITY AND FLAGGING. "Preserve every negation, every defined term's exact form, every cross-reference, every number and date, and the precise scope of every obligation. Do not narrow 'shall not be liable for any' into 'shall not be liable for', or broaden a specific carve-out into a general one. When a clause is ambiguous or a term's legal sense is uncertain, translate faithfully and add [FLAG: reason] immediately after.

The legal version follows the identical architecture and shows how portable the pattern is. The persona selects the legal register and, crucially, forbids the model's strong default instinct to modernize archaic contract phrasing into clean plain English, which would strip the legal force, an excellent example of a persona doing real, domain-specific register work that a generic prompt would get wrong. The glossary block resolves the genuinely dangerous near-synonyms: "termination," "rescission," and "cancellation" are not interchangeable in contract law, and a free legal persona might pick any of them, so the approved mapping is pinned and the alternatives are banned with their reason named. The grounding block targets the legal analogue of the invented contraindication: invented boilerplate. A legal persona, asked to sound like a contracts specialist, will happily "complete" a clause with the standard indemnity language it has seen a million times, and on a contract an added obligation is as damaging as a dropped one, so the grounding explicitly forbids it. And the fidelity block names the legal-specific critical errors, the narrowed liability exclusion, the broadened carve-out, the dropped negation that flips an obligation, which is where a confident legal voice does its real damage.

The architecture is identical across domains: persona selects the register the field demands, the glossary pins the exact approved terms and bans the dangerous near-synonyms, grounding forbids the model from supplying plausible content the source never had, and fidelity-plus-flagging catches the numbers, negations, scope, and residual ambiguity. The domain changes; the four-layer stack does not.

Operating the Technique Without Fooling Yourself

A technique this easy to misuse needs operating discipline, and four habits separate a practitioner who wields personas safely from one who has been seduced by the expert voice.

Name what the persona is for, in writing, and check it is register. Before adding a persona, finish the sentence "this persona exists to make the register..." If you cannot complete it with a specific register fact (more clinical, more formulaic, more cautious, less colloquial), the persona is theater and you should either delete it or replace your real intention with the control that actually serves it. This single habit kills most persona theater, because most theater happens when nobody articulated what the persona was supposed to change and just assumed "expert equals better."

Raise your vigilance on persona-styled output, do not lower it. Internalize that the polished domain voice is a property of the prompt, never evidence about the content. A persona-styled file is a higher-vigilance file, not a lower one, because the same error rates are present and better camouflaged. The post-editor's checks, against the source, against the glossary, on every negation and number and named condition, run with more skepticism on persona-styled MT, not less, precisely because the register heuristic that usually helps a reviewer has been weaponized against them.

Keep the layers in their lanes and state the precedence. The persona governs style only; the glossary and grounding govern content and terms and outrank the persona; the flag rule catches the rest. Write the precedence into the prompt so the model knows the approved term beats its trained preference. Never let a persona stand in for grounding or a glossary, because a persona offered as a substitute for content is the most dangerous form of the technique: confident, specific, plausible, and sourced from the wrong place.

The persona never moves the accountability. This is the line that carries through the whole program. A persona makes good register more probable; it makes nothing certain, and it makes no error less likely, only better disguised. "I told it to translate like a cardiologist" is no more an answer when a Critical error ships than "the engine wrote it" or "the system prompt told it to." The human who signs the delivery owns the quality, and the more authoritative the output's voice, the more deliberately that human has to refuse to be reassured by it. The revised ISO 18587 (the post-editing standard, now expanded to cover AI and LLM output) insists the post-editor hold full professional-translator competence precisely so that a human with real domain judgment, not a model wearing a domain costume, is the one accountable for the shipped string.

What Nadia Does Now

Nadia rebuilds the cardiology prompt as a stack instead of a costume. The persona stays, because it does real work: it fixes the register and stops the "heart attack" smoothing, and she can complete the sentence "this persona exists to make the register more clinical and conventionally phrased." But she subordinates it to a glossary that pins the client's approved terms and bans the near-synonyms, grounds the prompt so every contraindication and dose must come from the source and nowhere else, and adds the flag rule for the residual ambiguity. The invented contraindication that scared her is now explicitly forbidden by the grounding block, not because the model became more honest but because the prompt closed the door the persona had left open. And she briefs her post-editors on the thing that matters most: the new output reads more like a real cardiologist wrote it, and that is exactly why they have to trust it less, check the substance harder, and remember that the confident clinical voice is something she asked the engine to perform, not evidence that the engine knew what it was saying. The register got better. The vigilance went up to match. That, and not the impressive voice, is the technique working as it should.

Key Takeaways

• A persona (a role instruction naming who the model is), a domain constraint (the field it reasons inside), and a register (the formality and conventional style the content demands) together form a single move: prepend who/what-field/what-register to the task. Mechanically it does not teach the model anything or forbid it anything; it tilts the next-token probability distribution toward the region of training where the named specialist's language lives. It is a steering instruction, not a rule engine.
• A persona genuinely helps when the win is register, not accuracy: selecting a domain's conventional style (legal formulae, clinical caution) that differs from everyday language, disambiguating a word by field ("Anlage" as investment vs. enclosure), or matching house phrasing conventions to cut post-editing on style. The common thread is steering the model toward a register or sense the source uses but the model's generic default would miss.
• A persona is theater when there is no specialist register to select (a UI string, a plain tagline), when the real risk is accuracy and you reach for a persona instead of an accuracy control, or when it substitutes for grounding it cannot provide. The diagnostic question is "what would change if I removed the persona line?" If the honest answer is "I am hoping it would be more accurate," it is the wrong tool no matter how high the stakes.
• The central danger: authority of voice and accuracy of content are independent variables. A persona raises the first and leaves the second untouched, so it improves the disguise on every error it does not prevent. A clinical-sounding fabrication is harder to catch than a colloquial one, because reviewers use register as a heuristic for competence, a heuristic that is reliable for humans and catastrophic for machine output that can produce the register without the knowledge.
• The documented medical error rates (around 59% on drug names, 60% on dates/times, 66% on adverse events, all in perfect prose) are unchanged by a persona; tightening the clinical register can make each of those errors read more like authoritative clinical writing, routing a deadline-pressed reviewer's attention away from exactly the segments that need it.
• The correct architecture is a stack, not a single trick: the persona handles register; a glossary pins the exact approved terms and bans dangerous near-synonyms; grounding (feeding the model your real source, TM, and style assets) supplies specific content so claims come from your material not the model's training; and a flag-uncertainty rule catches the rest. The persona makes it sound right; the other layers make it be right.
• State the order of authority explicitly: grounding and glossary outrank the persona, and the prompt must say so, because the model will not otherwise know that an approved term beats its own domain-trained preference. Letting the persona's confident general voice override a specific approved term or a grounded prior decision is term drift wearing an expert costume.
• Operate it honestly: name in writing what register the persona is for (delete it if you cannot), raise vigilance on persona-styled output rather than lowering it, keep each layer in its lane, and remember the persona never moves accountability. "I told it to translate like a cardiologist" is no more a defense than "the engine wrote it"; the human who signs the delivery, holding the full-competence the revised ISO 18587 requires, owns the shipped string.