The card shows a small grid: one factual question asked three times under three role prompts. Each column gets a different answer shape. The lawyer column is cautious and qualification-heavy. The tutor column explains step by step. The casual assistant column is short and plain. Below the grid, a one-line do-and-don’t list warns against vague roles and contradictory persona text.
Role text works by biasing which training modes the model activates. Personas are not privileged access to new facts; they are priors over tone, structure, and how much uncertainty to surface. A medical framing nudges toward disclaimers. A coding framing nudges toward syntax and error checks. The effect is real but soft: the model can still hallucinate or overstate confidence while sounding like an expert.
Use roles to set audience and output contract, not to bypass safety or imply credentials the model does not have. Prefer specific, bounded roles: “explain to a first-year biology student in three short paragraphs” beats “you are an all-knowing scientist.” Align role with system instructions and do not fight them in the user message. If two roles appear in the same prompt, the model may blend them unpredictably.
For product design, role prompting is how you standardize voice across features without retraining. Put stable persona in the system message and keep the user message focused on the task. Test with adversarial user text that tries to break character; role alone is not a security boundary. The card’s lesson is comparative: same question, different hat, measurably different response, which makes persona an explicit engineering choice rather than an accident of phrasing.