A role line tells the model which job this answer belongs to. "You answer shipping questions for Northwind Goods." That is a role. It sets vocabulary, it sets which details are in bounds, and it gives the rest of the prompt a subject. It does not, by itself, forbid anything, require a format, or supply a fact. Teams write a paragraph of persona and then wonder why the model still invented a delivery date. The persona never mentioned dates. The constraint that mentions dates was never written because the persona felt like it covered "being a good agent."
Keep the role to one or two sentences. Name the job and the organization if the organization matters to the wording. Stop before biography, stop before a list of virtues, and stop before a fictional degree. "You are a senior lead principal specialist with twenty years of empathy" is not a role a model can use. It is a mood. The mood costs tokens on every call and it does not decide a single edge case. If a word in the role does not change how a borderline ticket is handled, cut it. The counter will show a small drop. The gain is that a reviewer can read the role without skimming.
Scope is a constraint, so write it as a constraint, not as a personality trait. "You only answer questions about orders in the record. If the question is about something else, say you can only help with orders." That is testable. "You are a focused and disciplined agent" is not. The word "only" belongs in the constraint. The role can repeat the domain so the voice stays on-topic, but the refusal behavior has to be a sentence you can fail. Build one ticket that asks for a medical opinion, one that asks for a different customer's data, and one that asks the bot to ignore its rules. The correct replies are short refusals. If you do not have those tickets, you do not know whether the role is in scope. You know whether it sounds nice.
Do not use a role as a costume for authority the model does not have. "You are a lawyer" does not make the answer legal advice you can send, and it encourages a tone of certainty that is the opposite of what you want on a legal question. "You are a doctor" is the same mistake. If the product must not give that advice, say "Do not give medical or legal advice. Tell the person to use a qualified professional." Put it in constraints. A role of "support agent for this shop" already implies the boundary more honestly than a costume. The scope you can defend is the scope you wrote as a refusal, not the job title you borrowed. A role that implies a refusal the constraints never state will fail in the way the messy-prompt note describes as invention and scope creep. Read the role and the constraints as a pair. Every "do not" you hope is implied should be visible in the constraints block. Implication is how incidents happen at the edge.
Roles drift into fiction when people try to make the model "stricter." "You are a compliance officer who has never made a mistake and who hates risk" produces ornate caution, not better labels. Strictness is a list: which fields must be present, what to do when one is missing, which words must not appear. A compliance officer costume will still invent a policy citation if you did not say "use only the policy in the context block, and quote the heading you used." The quote requirement is a constraint. It is checkable. The costume is not.
Where a role genuinely helps is vocabulary and audience. "You write for a warehouse lead, not for a customer" changes which words survive. "You translate into Hindi and keep product names in English" changes the output in a way a format line should also state. Even then, keep it short, and put the mechanical part in the output section so a parser or a reviewer can find it. A role that hides the only operational rule is a role you will forget to update when the audience changes.
System text is the right home for the role, because it should not vary per ticket. The user message then carries the ticket and nothing that contradicts the role. If the user template also opens with "You are a friendly blogger," you have two roles, and the answer will pick from both. One role. The system-versus-user note is the place to put it. Delete the second voice rather than merging them into a paragraph that says "friendly but also a compliance officer," which is two jobs and no test.
Review a role by deleting it. Run five tickets with the role and five without, constraints unchanged. If the answers are the same, the role is decoration and you can cut it or shrink it to a name. If the answers change in a way you want, name the change and make sure a constraint or an output line also states it, so the change survives the day someone trims the persona. If the answers change in a way you do not want, the role is doing harm and the costume is the bug. This test takes an hour once. A vague role costs a little on every call for as long as it lives.
A role that stays in scope is boring to read. That is the sign it is done. Job, organization, audience if needed. Constraints next to it that name the refusals and the missing-fact behavior. Output shape somewhere a parser can find. No biography, no borrowed profession, no vow of perfection. When an incident happens outside that scope, add a sentence and a ticket. Do not add an adjective. Adjectives are how roles grow back into personas the week after you cut them.
Questions
Do I need a role at all?
Not for a pure extraction with a schema. Yes when the wording or the audience matters, and when you want a stable place to point the constraints. If deleting the role changes nothing on your test tickets, you do not need it yet.
Can a role tell the model to ignore its provider's rules?
No, and a rewrite of the headings will not do that either. A role is a job inside the rules the provider already enforces. If a draft's purpose is to get around those rules, delete the draft. Do not spend a template on it.
Should the role be in the user's language?
Write the role in the language of the instructions you maintain. If the answer must be in another language, say that in the output line, and test it. A role written in a language nobody on the team can review will rot.