Maria finishes her draft note for the C-PTSD client at 9:40 PM and reads it back. It is accurate, it is on time, and something about it is off in a way she cannot name. Six years ago her supervisor would have named it in thirty seconds: "You documented the flashback like an incident report. Where is the client's window of tolerance? Where is the pacing decision you made when she started to dissociate?" That supervisor retired. The note will be signed by 10 PM either way. This lesson teaches persona engineering: building a prompt that asks a large language model to critique your draft note as if it were a board-approved trauma-informed supervisor reviewing your work, then pairing it with a second, colder persona, the payer concurrent-review nurse who decides whether your 90837 survives medical-necessity review. You will see the actual persona prompts, worked critiques on a fabricated note, and the discipline that keeps the technique honest: personas critique drafts, the clinician revises and signs, and no persona ever touches a clinical decision. You will finish with a Two-Persona Critique Workflow you can run on any draft note in under ten minutes.

What Persona Engineering Is, and What It Is Not

Persona engineering is the prompting technique of assigning the model a specific professional role, with explicit standards and review criteria, before asking it to evaluate your work. The difference between "review this note" and a built persona is the difference between asking a stranger in the hallway what they think and handing the draft to a named reviewer with a known rubric. A bare "review this" produces generic feedback: grammar, vagueness, maybe a suggestion to add detail. A persona prompt produces feedback through a lens: the trauma-informed supervisor reads for pacing, attunement, and stabilization language; the concurrent-review nurse reads for medical necessity, specificity, and billable justification. Same note, two lenses, two completely different lists of problems, and both lists are real.

Hold the controlling analogy for this lesson: persona engineering is hiring readers, not advisors. When a novelist sends a manuscript to beta readers, she chooses them for their lenses: one reads for plot holes, one for dialogue, one for whether chapter three drags. She does not let any of them rewrite the book, and she certainly does not let them decide how the story ends. The readers mark up the draft; the author decides what to change. Your personas are beta readers for clinical documentation. The trauma-informed supervisor persona marks where the note fails trauma-informed standards. The payer-nurse persona marks where the note fails medical-necessity review. You, the licensed clinician, decide which marks to accept, which to reject, and what the note finally says, because the signature at the bottom is a legal attestation and it is yours.

State the boundary now, before the technique gets attractive: a persona is a critique lens, never an authority. The model role-playing a supervisor is not a supervisor; it carries no board approval, no license, no accountability, and no knowledge of your client beyond the de-identified draft you showed it. It cannot supervise, cannot approve hours, cannot make or bless a clinical decision, and its critique of your risk documentation is commentary on prose, never a review of the risk assessment itself, which remains the clinician's determination from start to finish. Used inside that boundary, the technique gives a solo clinician at 9:40 PM something close to the thing private practice took away: a second reader who never gets tired.

The Anatomy of a Persona Prompt: Role, Standards, Output Contract

A working persona prompt has three layers, and most clinicians who try the technique and find it shallow skipped two of them. Layer one is the role: who the reviewer is, in enough professional detail that the model's training can locate the perspective. "You are a board-approved clinical supervisor with twenty years of trauma-focused practice" beats "act as a supervisor" because it pins seniority, specialization, and the supervisory frame. Layer two is the standards: the explicit criteria the persona reviews against. This is the layer that does the real work, because it converts the persona from costume to rubric. A trauma-informed supervisor persona without named standards will improvise plausible-sounding feedback; with named standards (pacing and titration documented, stabilization before processing, client's own words for trauma content, no gratuitous trauma detail, attunement and window-of-tolerance observations, strengths and survival adaptations framed as such), the critique becomes checkable against the criteria you specified.

Layer three is the output contract: the format and limits of the critique. Without it, the model rewrites your note, which is precisely what you do not want; the persona's job is to mark problems, not produce replacement text you might paste under fatigue. A clean output contract reads: "Do not rewrite the note. For each issue: quote the exact sentence, name the standard it fails, explain the failure in two sentences, and pose the question a supervisor would ask me. End with the two strongest aspects of the note." The quoting requirement keeps the critique anchored to text that actually exists (and makes hallucinated critiques instantly visible, because a quoted sentence that is not in your note is a fabrication you can catch in one glance). The question requirement matters more than it looks: a supervisor who tells you what to write replaces your judgment, while a supervisor who asks "what did you observe that told you she was leaving her window of tolerance?" forces your judgment to engage. Build your personas to ask, and the technique trains you instead of replacing you.

One privacy note before any persona reads anything: the draft you show the model follows the same rules as every AI workflow in this program. De-identify the draft, use a BAA-covered tool for anything client-derived, and for practice runs use fully fabricated notes. A persona prompt does not change what the tool is; it changes what the tool says.

The Trauma-Informed Supervisor Persona: Actual Prompt Text

Here is the full prompt, ready to adapt:

"You are a board-approved clinical supervisor with twenty years of trauma-focused practice supervising pre-licensed and licensed clinicians. Review the de-identified draft progress note below as you would a supervisee's work. Review only; do not rewrite the note, and do not comment on the clinical decisions themselves, which are the clinician's. Evaluate against these trauma-informed documentation standards: (1) pacing and titration decisions are documented, including any choice to slow or stop processing; (2) stabilization and grounding interventions appear before and after trauma content; (3) trauma material is referenced at the minimum level of detail needed for clinical continuity, with no gratuitous narrative; (4) the client's strengths and survival adaptations are framed as adaptations, not pathology; (5) attunement observations are present: affect shifts, dissociation markers, window-of-tolerance observations; (6) language is non-blaming and avoids re-traumatizing phrasing. For each issue: quote the exact sentence, name the standard it fails, explain the failure in two sentences, and pose the question you would ask me in supervision. End with the two strongest aspects of the note and one priority for my revision."

Run it against a fabricated draft and watch what comes back. Draft sentence: "Client described the assault in detail, became upset, and was calmed by the end of session." A generic reviewer calls that fine. The persona flags it three ways: standard 3 (the note invites detail where the record needs only "client processed index trauma material"), standard 5 ("became upset" is an attunement failure: upset how? tearful, dissociative, hyperaroused? where was she relative to her window of tolerance?), and standard 1 ("was calmed" hides the clinical work: what grounding intervention did you run, and what was the pacing decision?). Then the supervisory question: "When she became upset, what did you observe that guided your choice to continue or pause?" That question is the product. It sends you back into your memory of the session, and the revision you write from that memory ("client began to show dissociative markers, clinician paused processing and used grounding, client returned to window of tolerance within five minutes") is better documentation of work you actually did. The persona did not improve your note. It made you improve your note, which is what supervisors are for.

A persona is a hired reader, never an authority. The model marks the draft through a lens you chose; the clinician decides every revision, owns every clinical judgment, and signs the note as a legal attestation.

The Second Lens: The Payer Concurrent-Review Nurse Persona

Now pair the warm lens with the cold one. The concurrent-review nurse at the payer does not care about your attunement; she cares whether this note, standing alone, justifies the service billed. Her questions are brutal and fair: Is the intervention linked to the diagnosis? Why 90837 instead of 90834? Where is the medical necessity for this frequency? What measurable progress, or rationale for non-progress, does the note contain? The persona prompt:

"You are a concurrent-review nurse at a commercial payer conducting medical-necessity review of outpatient psychotherapy claims. Review the de-identified draft note below as you would in a utilization review. Do not rewrite it. Evaluate against these criteria: (1) the documented intervention is linked to the diagnosis and to a treatment plan goal; (2) the note justifies the specific CPT code billed, including session length for a 90837; (3) medical necessity for continued treatment at this frequency is evident from this note alone; (4) progress, or a clinical rationale for continued treatment without progress, is documented with specifics; (5) the note contains verifiable detail rather than generic phrasing that could describe any session. For each failure: quote the sentence or name the absence, state which criterion it fails, and state what a reviewer would conclude. End with a one-line determination: would this note survive concurrent review as written, and if not, what single addition matters most."

Run the same fabricated draft through this lens and the critique inverts. The sentence the supervisor persona praised for warmth ("client is making meaningful progress in processing her trauma") gets flagged as criterion 4 and 5 failure: meaningful how, measured by what? The nurse persona hunts for what AI cannot supply and a reviewer always checks: the actual time in session supporting the 90837, the specific symptom change (a PHQ-9 or PCL-5 movement, a sleep improvement in the client's words), the named modality actually used in the room. Those verifiable details are yours alone to add, because you were the only professional in the session. The persona can flag their absence; only you can fill them truthfully, and filling them with anything but the truth is fraud, no matter who drafted the sentence.

The two personas disagree, and the disagreement is the value. The supervisor wants minimal trauma detail; the nurse wants specificity. The supervisor praises process language; the nurse calls process language vague. A note that survives both lenses, trauma-informed and audit-proof at once, is a strong note, and writing toward both readers simultaneously is one of the highest-leverage documentation skills in this program. Run warm lens first, cold lens second, then reconcile: specificity about symptoms, function, and intervention satisfies the nurse without violating the supervisor's minimal-trauma-detail standard, because medical necessity lives in symptoms and function, not in the trauma narrative.

Reading Persona Critiques Without Being Ruled by Them

A persona critique is model output, which means it inherits every failure mode you have learned to audit. First failure: hallucinated critique. The output contract's quoting requirement is your tripwire; if the persona quotes a sentence that is not in your note, or critiques an omission of something the note actually contains, strike the item and trust the rest of the output less. Second failure: standards drift. The persona may critique against criteria you never gave it, sometimes usefully, sometimes importing generic documentation folklore that contradicts your jurisdiction or your payer's actual manual. Treat any critique outside your named standards as a suggestion from a stranger: interesting, unverified, yours to check against the real authority. Third failure: confident wrongness about rules. A persona asserting "Medicare requires X" or "trauma-informed care prohibits Y" is generating plausible text, not citing policy; rules get verified against the actual provider manual, the actual ethics code, the actual board regulation, never against a role-played reviewer's say-so.

There is also a subtler trap: writing for the persona. Run it on every note and you may start padding drafts with window-of-tolerance language the session did not contain, because you know the supervisor persona rewards it. That is the fabrication problem this program has warned about since the first scribe lesson, wearing a more sophisticated costume. The rule does not change: every sentence in the signed note describes something that actually happened. The persona can tell you a pacing decision is missing from the note. Whether a pacing decision happened in the room is a fact, and facts come from your memory of the session, not from the critique's appetite.

Finally, keep the persona's scope clinical-adjacent, never clinical. A persona may critique how a risk assessment is documented: is the plan specific, is the follow-up interval stated, is the rationale legible to a future reader? It never critiques whether the risk assessment was right, never proposes a different risk level, never opines on whether the Tarasoff threshold was met or the mandated report was required. Those determinations are the clinician's, made before any AI touches the note, and the program's standing rule covers persona play completely: AI structures, transcribes, and formats after the clinician's determination. A costume does not change what the actor is allowed to decide.

Building a Persona Library: Variations That Earn Their Place

Once the two core personas work, a small library of variants becomes a practice asset. A supervision-prep persona ("you are my clinical supervisor; given this de-identified case summary, what questions will you ask me in tomorrow's supervision?") turns the night before supervision into rehearsal, especially valuable for pre-licensed associates who get one supervision hour a week and want to spend it on the hard questions. A documentation-consistency persona ("review these three de-identified notes from the same case for internal contradictions in timeline, symptoms, and plan") catches the drift that creeps into long treatments. A new-clinician-explainer persona ("explain what is weak in this note as you would to a first-year associate") produces critique at a teaching register when the standard output is too terse to learn from. Group practice owners like Jordan can standardize a vetted persona pair across the practice, so every clinician's drafts meet the same two lenses before signature, converting an individual habit into a quality system the written AI policy can point to.

Resist library bloat. Every persona earns its place by producing critiques you act on; a persona you run and ignore is ritual, not review. And resist the seductive personas that cross the line: "act as a psychiatrist and tell me if this client needs medication" is not a critique lens, it is outsourced clinical judgment wearing a costume; "act as my client and tell me how she would react to this intervention" manufactures a fictional client voice and invites you to treat fabricated reactions as data. The test for any new persona is one question: does it review my work product, or does it simulate a judgment only a licensed human can make about a real human? Reviewers stay. Simulated deciders go.

A maintenance note: personas sharpen as your standards do. When a payer denial teaches you what the reviewer actually wanted, that lesson goes into the nurse persona's criteria. When a real supervisor or consultation group flags something in your documentation, that standard goes into the supervisor persona. The library becomes a living record of every hard documentation lesson you have learned, encoded so you never relearn it at 9:40 PM.

The Applied Problem: Build the Two-Persona Critique Workflow

Your artifact is the Two-Persona Critique Workflow: a saved, repeatable process that runs any draft note through both lenses and ends with your revision and signature. Build it in four steps.

Step one, install the two prompts. Copy the trauma-informed supervisor persona and the concurrent-review nurse persona from this lesson into your prompt library, then localize them: swap the supervisor's standards to match your modality and population (the six trauma-informed standards if you do trauma work; analogous standards from your framework if you do not), and load the nurse's criteria with your actual payer realities (the codes you bill, the documentation requirements from the provider manuals you live under). Add the output contract to both: quote exact sentences, name the standard, no rewriting, end with strengths and one priority.

Step two, write the run order and the rules of engagement as a header above the prompts: de-identified drafts only, BAA-covered tool for anything client-derived, warm lens first, cold lens second, and a hard rule that no persona output ever becomes note text by paste; revisions are written by you, from your memory of the session, in your words. Step three, test the workflow on a fabricated draft note you write badly on purpose: vague trauma detail, missing pacing decisions, generic progress language, no session minutes. Run both personas, verify every quoted sentence exists, strike any hallucinated critique, and revise the note yourself. Done at this step looks like a revision that satisfies both lenses: minimal trauma narrative with full clinical specificity about symptoms, function, intervention, and time.

Step four, add the verification footer that makes the workflow audit-safe: a four-line checklist you confirm before signing any persona-reviewed note. Every revision describes something that actually happened in session. Every verifiable detail (minutes, measures, modality) was supplied by me, not generated. No clinical determination (risk, diagnosis, report) was made or changed by a persona. I read every word, and the signature is mine. Store the whole artifact as one document: two prompts, run order, rules of engagement, verification footer. Ten minutes per note, two tireless readers, and the judgment exactly where your license requires it to be.

Key Takeaways

• Persona engineering assigns the model a specific professional role with explicit standards and an output contract, converting generic feedback into critique through a chosen lens. The controlling frame: personas are hired beta readers for your documentation, never advisors with authority, and the clinician decides every revision.
• A working persona prompt has three layers: the role (board-approved trauma-informed supervisor, payer concurrent-review nurse), the named standards it reviews against, and the output contract (quote exact sentences, name the failed standard, ask the supervisory question, never rewrite the note). Skip the standards or the contract and the technique goes shallow.
• The trauma-informed supervisor persona reviews for pacing and titration documentation, stabilization around trauma content, minimal trauma detail, strengths framed as adaptations, attunement and window-of-tolerance observations, and non-blaming language; its best output is the supervisory question that sends you back to your memory of the session.
• The payer concurrent-review nurse persona tests whether the note, standing alone, justifies the code billed: intervention linked to diagnosis and plan, 90837 session length, medical necessity at this frequency, specific progress or rationale, and verifiable detail only the clinician can truthfully supply (minutes, measure deltas, the modality actually used).
• The two lenses disagree by design: minimal trauma detail versus specificity. Reconciling them, specificity about symptoms and function rather than trauma narrative, produces notes that are trauma-informed and audit-proof at once, which is one of the highest-leverage documentation skills in the program.
• Persona critiques inherit every model failure mode: hallucinated critiques (caught by the quoting requirement), standards drift, and confident wrongness about rules, which are verified only against real provider manuals, ethics codes, and regulations. Never write for the persona; every signed sentence describes something that actually happened.
• Personas review work product; they never simulate clinical judgment. No persona scores risk, proposes a risk level, makes a Tarasoff or mandated-report determination, or decides a diagnosis or medication question, and a critique of risk documentation is commentary on prose, never on the clinician's determination, which is complete before AI touches the note.