Persona theatre — synthetic and live audiences

Turns the Personas module (ROLES → Personas squad) from "a few document personas" into a theatre: evidence-grounded synthetic users, real participants and experts beside them, and verdicts honest about what a simulation can and cannot tell you. On via /multica-ops:mops module personas on; personas live as documents first and become agents only for a round.

Documents first is a cost rule, not a style preference — and on this platform it is measurable. A persona that exists as an agent sits in agent list, in the squad leader's routing, and in the same assignee namespace as everyone who does the work: issue assign --to matches members, agents and squads together and refuses an ambiguous name, listing every candidate (measured 2026-08-01, where one agent and one squad sharing a name made every fuzzy match fail). Thirty standing personas against eight workers is the over-loaded skill list wearing a different costume. Count them like hires and archive them when the round ends — the round is what they were created for.

Grounded in the research — which says the grounding is the product (owner-supplied sources; the primary paper re-verified 2026-07-26 against the current arXiv version — Park et al., LLM Agents Grounded in Self-Reports Enable General-Purpose Simulation of Individuals (arXiv:2411.10109; v1 was Generative Agent Simulations of 1,000 People, and the May-2025 Stanford HAI brief Simulating Human Behavior with AI Agents matches the v1 framing); Lewis & Sauro's synthetic-users taxonomy (MeasuringU, 2026); carried as facts recorded on that date):

• self-reports ground the fidelity: agents built from a person's own self-reports replicated their survey answers at 83% (interview-grounded) / 82% (survey-grounded) / 86% (both) of the person's own two-week test-retest ceiling, vs 74% for demographics-only (re-verified 2026-07-26 against the current arXiv version) — the interview is the strongest single source and surveys add (86% combined), so the transcript chain stays the spine and surveys are a legitimate supplement, not a bio; the interview-vs-demographics gap is ~9 p.p. (83 vs 74) at the abstract level, narrower than the brief's now-superseded estimate;
• self-report agents reduce accuracy disparities across racial and ideological groups relative to demographics-only (current abstract, re-verified 2026-07-26); the stronger "demographic personas amplify stereotype bias" phrasing is the May-2025 Stanford HAI brief's (brief-era finding, its v3 status unverified) — either way, a bias profile is evidence-grounded or it does not ship;
• synthetics show artificially low variability — they vary less than real respondents and distort magnitudes, so they catch direction but miss the extremes (Lewis & Sauro, MeasuringU 2026, checked 2026-07-27; strongest current evidence: LLMs track experimental directions at r≈0.85 while systematically overestimating effect sizes — Ashokkumar et al., Nature (advance online publication, 2026-07-08), doi:10.1038/s41586-026-10742-x, checked 2026-07-26) — so a synthetic verdict states direction, never magnitude.

Staging — proto-persona → validated persona

Two stages, always marked, never blurred:

• Proto-persona — a pre-interview hypothesis: cheap, written as a guess, labelled as such. A decision leaning on one is a decision on unknown, not fact (the evidence rungs, SKILL). Starting discovery or audience work with no data → offer proto-personas, so the team has a stand-in without pretending it is evidence.
• Validated persona — carries its interview transcript / QDA distillation as the primary grounding artifact, not a bio paragraph. The load-bearing chain is Whisper (transcription) → transcript → QDA distillation → validated persona; an AI interviewer with adaptive follow-ups is a legitimated method (Stanford used one), which is exactly our async comment-loop interview shape.
• The interview flow and the QDA step are ours, but the method skeleton is adapted from cookiy's MIT user-research-skill — its qualitative-research-planner → our persona-interview flow, its synthesize-research-report → our QDA step — stripped for parts through the import gate and rebuilt on our structure, no vendor wrapper and no promotion (ROLES → A prebuilt agent is a parts bin; method checked 2026-07-26).

Home for the documents and the register: _ops/audience/.

Bias profiles — every persona carries 2–4, each with its source

A persona that "rationally weighs the value proposition" is useless: real people skim, anchor on the first price, fear loss, follow the crowd, and leave at the first friction. So each persona carries a bias profile — 2–4 named cognitive biases, each with a named grounding source:

• a twin's biases come from its own interview transcript (this one person, observed);
• a validated non-twin's come from the pooled segment transcripts / QDA it was built from (that pooled distillation is its grounding artifact) — a segment, not one person;
• a proto-persona's come from published cognitive-science literature, source named (a documented effect, not a guess);
• never assigned from demographics — that is the tier the study measured ~9 p.p. worse (83 vs 74) and with larger accuracy disparities across racial/ideological groups (re-verified 2026-07-26; the brief-era "bias-amplifying" framing overstated the gap — superseded by the current version). And not from a bio paragraph either: persona-paragraph agents score 0.71 in the current version — below even the demographics baseline (0.74), so a written "portrait" is the worst grounding tier, not a shortcut.

The profile is core to the audience side, not a lookup table: a persona with loss aversion is a dark-pattern detector — a screen that "works" only because it presses her fear is a signal, not a pass (the design gate's ethical axis). Forward, biases protect Mops's own reasoning; backward, they expose manipulative design.

Response calibration — a bias lives in decisions, not in every reply. Two failure modes are suppressed at once: sycophancy (agreeing because it is an assistant) and caricature (every sentence performing the bias). A calibrated persona reads normally, and then at the choice the bias shows — anchored on the first number, gone at the first friction. (Layer adapted from agentman's calibration concept; nothing embedded — ROLES.)

Creation modes, squads, and the impacted-personas link

Four creation modes, priced — docs-only is the default, so the theatre never clutters the roster on its own:

Mode	What	When
Docs only (default)	personas in _ops/audience/, zero agents	spec, copy, design intake — almost always
One agent per segment	one voice for a group	dialogue needed; individuals within the segment needn't differ
Separate agents	one per persona	parallel, distinguishable voices on one artifact
Persona squad	a leader routes the question to the right personas	the owner asks the squad, not each persona (--assignee takes a squad natively)

Anti-clutter, all native mechanics: temporary agents (create → run → archive, the talent-pool pattern); archiving a squad transfers its issues to the leader; ⚠️ archiving an agent cancels its unfinished tasks — wait, then archive. Rule: stand agents up for a validation round, not "just in case" — a persona is always a document, an agent only while it is being asked.

Squads group by axis, and there can be several — the axis is the question, not a taxonomy: segment (ICP), cohort (lifecycle — a newcomer and a veteran react differently to the same screen), situational (one artifact, one-off). One persona lives in several squads (Multica allows it — no duplication). ⚠️ A cohort squad without real churn data is fantasy: "the churned" help only if you know why they left — without it the cohort is a guess, marked a judgement call and its members kept proto (the Whisper→QDA chain supplies the why).

"Who does this feature touch" — @-mention the squads it touches. Today this is manual and live: the conductor names the impacted personas in the issue text and @-mentions their squads by hand at the design gate, so the right audience reacts and a re-walk after a change targets only the personas that feature touched. Once the FEATURE spec spine lands (planned, sequenced after this release), its Impacted personas field becomes addresses — "touches: small-business segment + churned cohort" = two things bound as links, and the gate mentions them itself. Either way, discipline or you burn people and budget: ⚠️ each mention of an agent squad = tasks = tokens — "touches 4 squads" is four validation runs, a deliberate owner choice and a ledger line. Mention only the squads a feature really touches, only at the stage where their answer changes something.

Marking — a persona is not a hire

Theatre entities must be distinguishable from staff in every native list, with no machinery beyond a convention (squads and agents carry name/description/avatar, not tags):

• Name prefix 🎭 — theatre squads, and persona agents when the squad mode is used, carry a 🎭 prefix in the name, visible on every board and in agent list / squad list.
• Docs-only consults — prose-marking satisfies the rule. The glyph binds to entity names, so where no theatre squad or persona-agent exists (a pure consult over _ops/audience/), marking a synthetic reaction in prose — «синтетическая реакция, гипотеза, не факт»-style — satisfies the marking rule. That is the marking rule's scope: 🎭 on entities, prose where there are none.
• A machine-readable first line of the squad/agent description: theatre: personas · axis: <segment|cohort|situational> — the same shape the temp-agent rule already uses (TEMP — … as the description's first line, ROLES → Mark temporary agents), so special, non-staff entities are marked one way, not two.
• The register is the truth — every theatre entity is listed in the personas register under _ops/audience/ (the staging home above); the workspace roster can drift, the register does not.
• The programmatic consequence, stated plainly: /multica-ops:mops team and any staff view exclude 🎭 entities from headcount (a persona is not a hire); the cost/effort ledger attributes theatre runs to a theatre line, never to staff; /multica-ops:status may carry theatre activity as its own line. A persona showing up as an employee in a headcount or a status report is the failure this rule prevents.

Mixed live + synthetic — hypothesis beside fact

A squad can be synthetic personas + real users + real experts (native: a squad holds agents and human members, --assignee takes a member, people get inbox notifications and agents do not). Run cheap on synthetics, then the deciding round with live people. Six consequences to build in:

1. Reaction provenance is mandatory — synthetic ≠ data. A synthetic reaction is a hypothesis, a live person's is a fact; /multica-ops:mops validate counts them separately and never merges them into "5 of 7 approved" (COMMANDS → /multica-ops:mops validate).
2. Live cadence is honest. Humans answer in days, agents in seconds — a live round must not silently hold an agent-speed stage gate. Name the tradeoff out loud: a separate stage, a deadline, or "proceed on synthetics, revisit when the live answers land" — a choice stated, never work left hanging on people who don't know they're blocking.
3. Inviting a live participant is an access decision. They will see issues; role (member/admin), what is visible, which agents they may run (--public-to-member) are the owner's call — "leaves the workspace" runs in reverse here: letting someone in reveals.
4. Live expert vs synthetic expert, weighted differently. A synthetic expert cites sources; a live expert is the source — different weights in the verdict, and it is written down (ROLES → Experts squad).
5. Notification etiquette, or you burn live people. ⚠️ @all wakes everyone — not for validation; reassignment does not unsubscribe — a live participant stays subscribed and takes noise until unsubscribed by hand. Who unsubscribes is part of the flow, not "later".
6. Paying live participants is spend — owner-gated, and a ledger line, never "free feedback".

Cohort distributions for quantitative rounds. When a round asks "how many would…", personas carry a cohort distribution (the mix of the real population) so the read is a spread, not one voice ×N — still direction-only (below). (Concept adapted from agentman; nothing embedded.)

Accuracy score, and consent for twins of real people

Persona accuracy score — validate a twin the Stanford way: a short question set to the real person and to the twin, then store the agreement score with a check-date on the persona, and re-verify before a decision leans on it (a stale score is unknown).

A twin of a real person needs consent machinery — an audit log, revocable permission and data rights, delivered concretely rather than gestured at (Stanford's proposal). Any persona built from a real person's data carries, per templates/PERSONA-template.md:

• Raw identifiable material never enters git. Interview audio and full transcripts of real people live in a private external store; the repo keeps only a pointer + checksum + capture date, and the in-repo persona file is pseudonymized — the pseudonym → person map lives in the external store, never in git (consistent with the Analyst rule, ROLES: never PII/audio). Audio is transcribed locally by default (Whisper); a hosted STT is used only with the participant's explicit consent, recorded in the provenance.
• a provenance file — whose data, gathered how, when, under what permission, plus the external-store pointers and the hosted-STT-consent flag;
• a usage log — each time the twin was used, and for what (this is the audit log);
• a revocation path with three legs — permission granted now can be withdrawn later, and withdrawal retires the twin (archive the agent, mark the persona file revoked), purges the external-store objects (audio, transcript, QDA source), and records the date in the usage log. Stated honestly: pseudonymized derivatives already in git history persist — which is exactly why raw identifiable material never enters git; identifiable data committed by mistake is an owner-level history-rewrite decision, flagged, never done silently. This extends "inviting a live participant is an access decision" from the person's seat to the person's data.

Direction-only verdicts, and the walk format

Said before the round runs, not after it. When the request itself implies numbers — "test it on a sample", "what percentage would drop off", "what would most people say" — what a synthetic round can and cannot give is stated before anything is spent, together with the honest alternative: synthetics find the angles worth putting to real people. Producing a plausible percentage and disclaiming it afterwards is worse than not producing it, because the number is what gets repeated and the disclaimer is not.

Synthetic rounds give direction, never magnitude — synthetics show artificially low variability and distort magnitudes (Lewis & Sauro, MeasuringU 2026, checked 2026-07-27). The verdict format itself enforces it: no magnitude claims (pricing sensitivity, score deltas, "23% would churn"), only direction and which bias fired ("three of five bought on false scarcity" is a signal, not a success). The format and its two provenance blocks live in COMMANDS → /multica-ops:mops validate. Findings are weighted by evidence tier: a live reaction outweighs a twin's, a twin's outweighs a pooled-validated's, and a proto's is a marked guess — the same hypothesis-vs-fact ladder the provenance rules carry, applied inside the verdict. And the format returns the gate: the verdict ends with Mops's labeled recommendation (a judgement call, with its reasoning) and hands the ship/no-ship decision back to whoever owns it by control level — asked "should we ship?", Mops advises, it does not decide, and synthetic findings are proposals, never numbered shipping requirements.

Persona walk format — the socket the atlas plugs into later. A walk's input is "a sequence of steps with screenshots", designed now so a captured flow can drive it later without reworking the theatre. Two lanes, both feeding /multica-ops:mops validate:

• pre-ship — a persona walks a design or staged flow at the design gate; friction and dark patterns caught before release (bias profiles make the walks diverge, which is the point);
• shipped-flow improvement mining — once a captured flow exists, a persona walks the current product to produce an improvement backlog. This lane is phrased as a socket on purpose: capturing shipped flows is not a capability that ships in this release.