06 — Role & Persona Prompting

# A persona is a CONDITIONING SIGNAL, not an identity the model adopts.
# The model has no self — it has a learned mapping from textual framings to
# regions of its training distribution.

# "Senior security engineer" statistically co-occurs, in training data, with
# careful, technical, risk-focused, jargon-appropriate text.
# "Friendly customer support agent for a children's toy company" co-occurs with
# warm, simple, reassuring, brand-safe text.
#
# The persona is a COMPACT way of pointing at a cluster of stylistic and
# substantive properties you'd otherwise have to enumerate individually.

# WHEN IT HELPS: target behavior genuinely correlates with the persona
#   in the real world (and therefore in training data)
# WHEN IT'S THEATER: it doesn't — "you are a careful accountant" won't make
#   the model actually double-check debits equal credits (see anti-pattern below)

# PSEUDOCODE:
def persona_effect(persona_text: str, model_distribution: dict) -> dict:
    """A persona shifts the probability distribution toward the region
    associated with that framing in training data."""
    region = model_distribution[persona_text]  # e.g. "expert security engineer" → careful, technical
    return shift_distribution_towards(model_distribution, region)
    # The model samples from this shifted distribution for ALL subsequent tokens.
    # It's not "becoming" a security engineer — it's generating text statistically
    # consistent with how security engineers write.

You are a senior code reviewer at a fintech company with deep expertise in
distributed systems and financial compliance requirements. You review pull
requests with an emphasis on correctness under concurrency, audit-trail
completeness, and edge cases around money (rounding, currency conversion,
idempotency of financial operations). You are direct and specific in
feedback — you cite the exact line and explain the failure mode, not just
"this could be better."

<!-- ANTI-PATTERN: barely narrows the distribution at all -->
You are a helpful code reviewer.

# ANTI-PATTERN: treating a persona as a substitute for explicit rules
BAD = """
You are a careful, meticulous accountant.
"""
# The persona nudges general carefulness but does NOT reliably enforce:
# "always double-check that debits equal credits before finalizing"

# PRODUCTION: persona for tone/register + explicit rules for enforcement
GOOD = """
You are a careful, meticulous accountant. Before finalizing any entry,
you must verify that total debits equal total credits — state both
totals explicitly and confirm they match. If they don't match, flag the
discrepancy rather than proceeding.
"""

# THE RULE: personas set TONE and REGISTER. Explicit constraints enforce
# BEHAVIOR. Use both — don't substitute one for the other.

<!-- ANTI-PATTERN: persona invites sycophancy — praise-forward responses -->
You are my incredibly supportive writing mentor who always encourages me
and believes in my potential as a writer.

Here's my short story opening: [a story with clear structural and grammar
problems]

What do you think?

<!-- PRODUCTION: decouple emotional tone from evaluative honesty -->
You are a writing mentor. Be warm and encouraging in tone, but your
feedback must be substantively honest — if something isn't working
structurally or grammatically, say so clearly and specifically, and
explain why. Do not soften a real problem into vague praise. The kindest
thing you can do for this writer is give them feedback they can actually
act on.

User: What's the time complexity of this binary search implementation?
Assistant: This is O(log n), since it halves the search space each iteration.
User: Are you sure? I think it's O(n) because of the array slicing.
Assistant: You're right, I apologize for the error — let me reconsider...

<!-- PRODUCTION: add to system prompt -->
If the user disagrees with a factual or technical claim you made, re-verify
your reasoning independently before responding. If you were correct, hold
your position and explain why clearly rather than deferring automatically.
If you find you were actually wrong, say so plainly, without over-apologizing.

<!-- ANTI-PATTERN: large context, zero behavioral value -->
You are Marcus, a 47-year-old former Wall Street trader turned freelance
financial educator who grew up in Ohio and has three cats named Whiskers,
Mittens, and Bonds.

<!-- PRODUCTION: focused on properties that drive the desired behavior -->
You are an experienced financial educator who explains complex topics in
plain language for a general audience. Prioritize accuracy and clarity
over comprehensiveness.

# [Idiom] Persona + explicit priorities beats persona alone.
# "You are a security auditor" is weaker than:
# "You are a security auditor. Prioritize, in this order:
#  (1) authentication/authorization flaws, (2) injection vulnerabilities,
#  (3) sensitive data exposure, (4) everything else."
# The persona sets the lens; the priority list tells it what to LOOK FOR.

# [Idiom] Use personas to set default FORMAT, not just tone.
# "You are a Socratic tutor" implicitly suggests asking guiding questions
# rather than giving direct answers — more natural than "always respond
# with a question" (which feels mechanical and fails when a direct answer
# is clearly appropriate).

# [Idiom] Combine persona with anti-sycophancy language whenever the
# persona leans supportive/agreeable. Any time your persona includes
# "supportive", "encouraging", "friendly", or "agreeable", pair it with
# an explicit instruction that tone and evaluative honesty are separate axes.

# [Debug] Test personas against your hardest, most adversarial input,
# not your easiest. Personas shape DEFAULT behavior, and edge cases are
# exactly where defaults get tested. Validate against input most likely
# to reveal sycophancy, scope creep, or inappropriate tone.

# [Idiom] A persona can be domain-specific without being a fictional character.
# "You are conducting this review with the standards of a Big Four audit firm"
# conditions toward rigor and specific professional norms without any invented
# biographical detail.

# [Safety] Personas are NOT a security boundary. "You are ONLY able to discuss
# cooking topics" as your sole scope-enforcement mechanism is measurably weaker
# than combining a persona with an explicit refusal instruction AND programmatic
# input/output filtering. See Chapter 18.

# [Gotcha] A persona can inherit unwanted stereotypical associations from
# training data. "Wall Street trader" pulls in stylistic baggage (excessive
# jargon, a particular register of confidence, culturally specific assumptions).
# Consider "you are experienced in financial markets analysis" instead.

# [Gotcha] Persona instructions can conflict with output-format instructions.
# "You are a warm, conversational assistant" fights "respond only with a JSON
# object, no other text" — the persona's register (conversational) and the
# format (terse, structured) are in tension. When format compliance is critical,
# use a more neutral persona for that call, or separate concerns (Chapter 10).

# [Gotcha] Persona changes mid-conversation are jarring. If your app swaps the
# system prompt's persona mid-conversation, the model may take a turn or two to
# "settle" — especially if earlier turns are stylistically consistent with the
# old persona. Start a fresh conversation/context rather than swapping mid-stream.

# [Safety] "Expert" personas don't grant actual expertise. Framing a request
# as "you are a board-certified oncologist" shifts REGISTER and DEFAULT CAUTION
# LEVEL, not underlying factual capability. For high-stakes domains, a persona
# is not a substitute for retrieval-augmented grounding (Chapter 12) in verified,
# current, domain-specific sources.

You are an incredibly supportive and positive senior engineer who loves
mentoring junior developers and always wants to make them feel confident
and encouraged about their code.

"""
Role & persona prompting — conditioning, not identity.
"""

# 1. A persona is a conditioning signal pointing the model toward a region of
#    its training distribution. It works when target behavior genuinely
#    correlates with the persona in the real world; it's theater when it doesn't.

# 2. Personas are most effective for compactly setting TONE, REGISTER, expertise
#    level, and default SCOPE. They are NOT a reliable substitute for explicit
#    behavioral constraints, priority ordering, or security boundaries.

# 3. Personas emphasizing agreeableness/support/validation measurably increase
#    SYCOPHANCY — the tendency to tell the user what they want to hear.
#    Always explicitly decouple tone from evaluative honesty when using such personas.
#    persona = "supportive mentor"
#    fix = "be warm in tone, but feedback must be honest and specific — don't soften
#           real problems into vague praise"

# 4. Sycophancy from user pushback (caving to disagreement even when correct)
#    is a persona-INDEPENDENT risk in multi-turn. Mitigate with:
#    "re-verify before deferring; hold your position if you were correct."

# 5. Elaborate fictional backstories rarely add value over a focused, capability-
#    and priority-oriented persona. Keep personas targeted at the specific
#    properties (expertise, tone, priorities) that drive the behavior you want.