Deep Persona Wizard v20

Full report

On this page

• Multi-step persona builder (25 steps, 206 options): The new wizard guides creation of a detailed persona by asking for name, identity (including gender identity and pronouns), sexual/romantic orientations, demographics, civic worldview (ideology + issue positions), and other traits. It explicitly separates each aspect (e.g. gender identity vs. presentation) and never infers unasked information. Notably, sexual and romantic orientation are separate fields, aligning with the psychological “split attraction” model that treats these as independent. For example, the wizard randomizes gender as male or female by default and straight/heterosexual by default, but allows explicit selection of a wide range of identities (14 gender identities, 10 pronoun sets, 17 sexual orientations, 11 romantic orientations, etc.). This explicit user-provided data approach is consistent with accessibility best practices: designers are instructed not to guess or impose a person’s gender or orientation from appearance.
• Avoidance of bias and stereotypes: Gender and orientation fields must be chosen by the user (or set randomly among a safe default) rather than inferred from other inputs. This follows accessibility guidelines (e.g. alt-text guidelines recommend “Don’t guess someone’s gender”). The wizard’s invariants specify that any explicit override is preserved and that orientation/gender are not changed without user input. Other safeguards (e.g. not using demographic labels as shortcuts for intelligence or warmth) echo fairness principles in AI.
• Focus on realism and coherence: Instead of relying on generic role labels or vague traits, the persona is constructed as a realistic individual. The wizard requires a realistic personal name and separates “short personality summary” (a brief descriptor) from the name/title. This ensures output persona narratives use a person’s name and traits rather than impersonal archetypes. By structuring the persona explicitly (identity → worldview → behavior), it enforces a coherent character, as recommended in persona design research (e.g. using Big Five trait dimensions rather than loose labels).

Key Data & Design: The wizard has 25 interactive steps covering identity (e.g. Gender, “pronouns and presentation”), orientation, demographics, and worldview. Altogether it offers 206 selectable options. For example, Gender identity presents 14 choices (including man, woman, nonbinary, agender, trans-persons, etc.), Pronouns has 10 presets (e.g. he/him, she/her, they/them, name-only, etc.), and Civic worldview asks for an ideology (from 21 options) plus issue stances. Identities are preserved: gender/orientation once set are never overwritten or defaulted to unrelated answers. The wizard’s JSON schema (machine-readable catalog) enforces all inputs and invariants (e.g. “no replacement of name with a role label”).

Methodology & Scope: This document is a design spec, not a research study. It consolidates internal UX decisions guided by earlier persona studies. No empirical data collection is reported here. The design is ad-hoc but research-informed: for instance, it explicitly encodes the split attraction model of sexuality and aligns with published UX guidelines (like not inferring gender). There is no statistical analysis or sampling; rather, the methodology is specification-driven design.

Corroboration & Context: The wizard’s approach follows established accessibility and fairness guidelines. Notably, image alt-text best practices advise never to guess a person’s gender or sexual identity from their appearance, matching the wizard’s rule that orientation/gender are only used if explicitly given. The notion of separating sexual vs. romantic orientation is supported by sexuality research: the split attraction model treats romantic and sexual attraction as distinct variables. The emphasis on realistic names and personal summaries aligns with UX research on believable characters (e.g. requiring plausible personal names rather than arbitrary labels). At the same time, some design choices invite scrutiny. For example, randomization is limited to binary gender and heterosexual orientation by default – an area where fairness advocates might question why nonbinary or LGBT defaults are excluded from randomness. The provided materials do not cite external studies on this, so it remains an internal policy.

Recommendations & Next Steps: To improve robustness, we recommend evaluating the wizard with diverse users. For example, test whether the forced default of “man/woman, straight” biases personas unduly (given that surveys show non-heterosexual identities occur in noticeable minorities). Follow-up could gather user preferences on default categories and adjust the randomization policy. Another action is to verify persona outputs via audits: ensure no personal identity (race, religion, etc.) is inferred or stereotyped in generated content (current rules forbid this). Finally, consider extending metadata (e.g. adding fields like race/ethnicity or religion if needed for some contexts) or explicitly justifying their omission.

Canonical Persona Schema v20

• Structured persona definition: The schema defines the canonical JSON format for a persona. Required top-level fields include identity.name (a realistic personal name), identity.title, identity.shortPersonalitySummary (a brief descriptor like “Warm Synthesis Cartographer”), and identity.career. It also embeds demographics (name culture, gender identity, pronouns, etc.) and civicWorldview (ideology, conviction strength, engagement level, issuePositions, etc.). These structured fields ensure each persona has a fully fleshed-out “profile” rather than only a textual description.
• Semantic clarity and migration: Each field’s meaning is explicitly documented (e.g. identity.name must be a “realistic personal name”). The schema also includes migration rules from older versions, and a fingerprinting mechanism to track the source of persona data. This mirrors database best practices of using strict schemas and versioning to maintain data integrity.
• Artifact contracts: The schema enforces a “single-source” rule: all persona outputs (JSON, prompts, memory state) must derive from one canonical profile. This avoids fragmentation. It also specifies portable outputs (e.g. a Canonical JSON profile, a “Persona Seed” for reconstruction, Persona Prompt, memory capsule, etc.). These detail what artifacts a complete persona export should include.

Key Data & Structure: The schema is largely normative, listing required JSON keys and contracts. For example, the civicWorldview object must have fields like ideology (with id/label), strength (score 0–100), engagement (categorical), and per-issue stances. The schema also lists which fields are invariant (e.g. personaId and fingerprint). The “minimum portable depth” bullet list enumerates all data that must travel with the persona (e.g. values, portraits, motives, memory caps, etc.).

Methodology & Bias: This is a standards document; no empirical method is used beyond specification-writing. It implicitly encodes design priorities (e.g. how identity should be broken out). There is an inherent bias toward a very structured, attribute-based persona model. For example, requiring an explicit shortPersonalitySummary and career field may not fit simpler persona use-cases, but this is an intentional design choice to standardize profiles. No statistical bias is present, but the schema’s rigidity could be critiqued if it inadvertently excludes alternative persona frameworks.

Corroboration & Context: The schema’s approach is similar to standard data modeling in software and user-profile systems. For instance, it parallels CRM or identity systems that separate personal info (name, culture) from preferences or roles. The idea of a separate “short summary” is akin to character description fields found in literary persona templates. However, there is no direct external benchmark for this specific schema; it appears internally devised. Its emphasis on civic/worldview is unusual relative to most persona systems, so validation could come from political psychology sources: e.g. surveys like Pew’s show multi-dimensional beliefs beyond party labels, which justifies having a rich worldview object rather than just “party affiliation.”

Recommendations & Next Steps: Review this schema against real-world persona use cases. For instance, we suggest a gap analysis: does it cover cases like organizational roles, or non-Western cultural norms? It currently includes 15 name cultures and labels an honorific set; ensure these reflect the intended demographic scope. We also recommend linking this schema to any API or UX design guidelines to ensure consistency. Finally, consider adding soft constraints or advice: e.g. how to generate a valid shortPersonalitySummary in practice.

Persona Research-to-Runtime Crosswalk v20

• Research findings → implementation mapping: This document lists key persona research insights and how they are applied in the system. For example, it notes that androgynous personas should balance masculine and feminine cues, and that alt text should not guess gender from an image. The system addresses these by (respectively) adjusting portrait prompts and enforcing factual alt descriptions. These prescriptions match known guidelines: for instance, web accessibility guidance explicitly warns, “Don’t guess at someone’s gender” when writing alt text, which is implemented here as never inferring invisible traits.
• Personality dimensionality: It highlights that “Trait science is dimensional” (citing Big Five personality models) and that identity labels alone (like “man” or “woman”) are insufficient for personality. The implementation thus uses continuous psychometric coordinates (Big Five/HEXACO) instead of coarse categorical types. This conforms to mainstream personality psychology: decades of research show that human personality is best described by continuous factors (the Five-Factor Model), not rigid categories.
• Political worldview nuance: The crosswalk notes that U.S. political labels (e.g. Republican/Democrat) are too coarse. Instead, it implements a spectrum of ideologies and issue positions. This reflects modern polling research: for example, Pew’s 2026 political typology finds that Americans’ beliefs fall into nine distinct groups based on values, transcending a simple red/blue divide. The system’s use of 21 ideological IDs and multiple issue stances aligns with that complexity.

Key Points & Evidence: The table connects research observations to concrete features. For example, “Alternate terms: wavy hair→4 options” is an implementation detail (not easily externally verified). But the rationale (like not inferring political views from appearance) has broad support in bias-mitigation literature. The Big Five reference is supported by psychological studies (e.g. “five broad dimensions explain most variation in personality”). The separate orientation fields are explicitly backed by the Split Attraction Model research.

Methodology & Bias: This is a design synoptic table, not an empirical study. It is biased toward self-consistency: it asserts that previous research “must be retained” and directly mapped. Potential weaknesses: it relies on internal “prior research” claims (many bolded points lack citations) and assumes they are valid. There is no systematic literature review cited here. For example, the “androgynous persona portrait report” is referenced but not publicly evaluated. The table also takes for granted that trade-offs (e.g. 4 hair style options for gender-neutral) are effective; it does not provide user testing results.

Corroboration & Contradiction: Where external sources exist, they generally support these ideas. For instance, the warning against using demographic labels as proxies for competence or morality is a standard AI fairness principle (e.g. ethics guidelines disallow stereotyping protected groups). The importance of explicit identities and user consent in persona creation has parallels in UX/AI ethics: user-defined personas are often encouraged over system-imposed stereotypes. There is no obvious contradiction to key claims. However, one might note that some researchers do use prototypical images or archetypes to convey persona (the system rejects this), so this approach is on the more conservative/explicit end.

Recommendations & Next Steps: Some crosswalk items suggest further validation. For example, the “balanced facial features” approach for androgynous portraits could be tested: does it indeed produce images perceived as nonbinary by users? The Big Five psychometrics could be calibrated with external standard tests (e.g. NEO-PI-R data) to ensure consistency. We also suggest reviewing emerging persona research (e.g. on multi-cultural narratives) to update this table. If possible, publish and link some of these internal “research findings” (like the androgynous report) to get external scrutiny.

Persona Export Contract v20

• Atomic export rule: Every persona export is a single, complete canonical profile. The document mandates no splitting a persona into multiple exports. This ensures consistency: an agent’s full state (identity, memory, etc.) travels together. In practice this is like an ACID “all-or-nothing” export.
• Field semantics: The contract defines each field’s intended use. For instance, identity.name is explicitly “realistic personal name” and not a role label. Similarly, identity.shortPersonalitySummary must not be merged with the name or career field; they are separate. This precision avoids ambiguity. While such specifics are internal, they echo common API design patterns where each JSON field has a strict schema and meaning.
• Required outputs: It lists all artifacts required for a valid persona export: JSON profile, prompt strings, memory capsule, etc. This thoroughness helps ensure no piece is forgotten. The notion of a “memory capsule” or “UAI modules” (serialized personality components) is proprietary but follows the general principle of saving both raw data and compiled outputs.
• Portable depth and privacy: The contract enumerates what must carry over if a persona is transferred, including “drives, tensions, values, portrait guidelines,” etc. Notably, it excludes any private data (e.g. credentials) – a user privacy guardrail. The emphasis on preventing leaking sensitive info follows best practices like zero-trust: only share what’s needed for persona functionality.

Extracted Details: The report is essentially a policy, with no empirical data. Key details include a table of required field semantics (e.g. identity.title is “formal name”), and a bullet list of minimum portable depth (about 15 points, including persona voice, memory, relationship state, etc.). It also defines identity invariants (personaId + fingerprint must persist) and states that export is done client-side for privacy.

Methodology & Bias: As a specification, it’s normative. Its “bias” is toward maximum portability and consistency. One could critique it for possible rigidity: for example, requiring all memory tiers and all persona parameters might be overkill for simpler applications. There is no measured evaluation of whether these requirements are user-friendly.

Corroboration & Context: Much of this aligns with general data-engineering wisdom. For example, preserving a unique ID and version/hash is like Git’s commit hashes for integrity. The idea of excluding private details from data exports matches GDPR-style data minimization. No formal standards body defines “persona export,” so we have no direct external specs to cite. However, analogous domains (like LLM “state-sharing” frameworks) also emphasize bundling context and avoiding PII. This contract resembles a thorough API or SDK design document.

Recommendations & Next Steps: An action item is to peer-review these requirements: ensure no needed artifact is omitted, and nothing unnecessary is enforced. For instance, is storing both portraitGuidance and alt-text prompt redundant? Could some fields be optional if unused? Another follow-up is to develop compliance tests: automated checks that an export package truly contains all listed components and respects the invariants. Finally, it might be useful to compare with other persona-export formats (if any exist in literature or industry) to identify best practices.

Identity, Demographics, and Worldview Engine v20

• Identity model as core persona input: The report emphasizes that “identity” is not just metadata but central behavioral context. It defines an identity JSON block with fields like givenName, familyName, shortPersonalitySummary, career, etc. An example JSON shows “Elena Marquez, Dr. Elena Marquez,” highlighting use of both a formal title and a personal name. This richer identity scaffolding (honorifics, title, name culture) is uncommon in basic chatbot profiles but reflects a push for realism.
• Name generation: A deterministic name generator is described: it uses culture-specific pools (15 cultures, ~1136 names total). Gender selection influences default name choices, and a random seed yields reproducible names. This approach parallels usual language generation methods (e.g. choosing from name lists), but scaled to multiple cultures. It aligns with sociolinguistic practice: names should fit the persona’s background. No external reference is given, but this is a straightforward design choice consistent with text generation norms.
• Expanded gender & pronoun options: The engine lists 14 supported gender identities (man, woman, nonbinary, agender, fluid, queer, bigender, demiboy/girl, trans-woman/man, androgynous-ambiguous, none, custom) and 10 pronoun sets (he/him, she/her, they/them, he/they, she/they, ze/zir, xe/xem, it/its, any, name-only). These are broader than classic systems. The inclusion of “androgynous-ambiguous” specifically triggers a special portrait mode. These categories are generally consistent with modern LGBTQ+ terminology. For example, resources like the Trevor Project enumerate a similarly wide set of identities (agender, demiboy, etc.). The pronoun list includes both common ones (they/them) and less common (ze/zir, it/its). (Note: mainstream style guides vary on “it/its” pronouns, but here it is permitted as user-chosen.)
• Sexual and romantic orientation model: Sexual and romantic orientations are stored separately. The document states random generation yields heterosexual by default (“straight” and “heteroromantic”), but any of 17 sexual and 11 romantic orientations are available. The principle that “romantic and sexual attraction are not strictly linked” is backed by research (split attraction model). The implementation follows this idea. It also notes that orientation is only used if relevant to context (matching the accessibility advice to only mention identity traits when contextually needed).
• Civic worldview engine: This section introduces a structured civicWorldview JSON, including fields like ideology (id/label, e.g. Green/Ecological), strength (how strongly held, with a numeric score), engagement (political activism level), and detailed issuePositions. It also includes rules (disagreementRule, etc.) to govern how worldview influences dialogue. This granular modeling (ideology + per-issue stance) is unusual for chatbots but parallels survey research where ideology and policy positions are measured separately. As noted in the Implementation Summary, these track major policy domains (economy, environment, etc.) and include norms (never assume that a persona’s political label reveals unrelated traits like intelligence). This matches political science findings that labels alone don’t predict all issue stances.

Notable Safeguards: The engine enforces several “behavioral safeguards” to avoid bias. For example, it forbids inferring intelligence, competence, morality, warmth or dominance from demographic attributes. This echoes AI ethics guidelines (which warn against attributing qualities based on protected attributes). It also requires portrait prompts to describe only visible, relevant features (consistent with WCAG alt-text advice) and to use pronouns only as the user has specified. For instance, alt-text is factual (“Elena Marquez sitting”) and never guesses hidden traits.

Methodology & Bias: This is an internal design description. It draws on prior research (the androgynous portrait report, personality research, etc.) but does not conduct new experiments. The gender/orientation design assumes certain defaults (e.g. random defaults to straight; gender defaults name pools). One could critique that these defaults encode heteronormative bias: starting straight by default, for example, reflects historical norms. The set of gender identities is broad, but it is unclear how often the system will use them in practice, given the randomization policy. There is no validation data here – one would need to test how well these identity choices perform in real conversations.

Corroboration & Context: As with other sections, many design points align with external guidance. The pronoun options (she/her, they/them, ze/zir, etc.) match lists found in LGBTQ resource centers. The insistence on asking for user preferences (“if provided, use that name/pronouns”) is standard inclusive design. The orientation model reflects academic consensus that romantic and sexual orientations can diverge. The civic worldview fields are more novel, but the breakdown into ideology, strength, engagement, and issues is reminiscent of political survey instruments. For example, Gallup’s ideology polls use a 5-point scale, and engagement is often measured categorically – this engine uses a 7-point strength score and 6 levels of activism, which seems plausible.

Recommendations & Next Steps: One gap is that the engine does not explicitly include attributes like race/ethnicity or religion (aside from “name culture”). This could be a deliberate omission to avoid stereotyping, but if relevant, adding fields (with similar safeguards) could be considered. Also, the practical performance of androgynous portrait generation should be user-tested: verifying that the balanced-cue prompts actually yield images perceived as non-gendered. The orientation model could be expanded over time to include lesser-known identities as they emerge. It would also be prudent to monitor the randomization policies (binary gender, straight default) for any systematic bias in outcomes. Finally, cross-cultural validity (15 cultures) should be checked with demographic data: e.g. do the name pools fairly represent global usage?

Implementation Summary: v20 Identity–Worldview Engine

• Primary semantic correction: The release emphasizes that identity fields have been overhauled. A summary table redefines identity.name (personal name), identity.title (honorific prefix), identity.shortPersonalitySummary, and identity.career. For example, the name “Elena Marquez” and title “Dr. Elena Marquez” are split. This ensures no “role label” slips into the name field. The short summary is treated as a distinct personality label. These align with the canonical schema semantics and fix earlier conflations.
• Random vs. manual policies: It explicitly states that the random persona builder chooses only man or woman for gender, and defaults orientations to straight/hetero. By contrast, manual builders (wizard/API) expose all catalog options: 14 gender, 10 pronouns, 8 presentations, 17 sexual, 11 romantic, 15 name cultures, 15 honorifics, etc. This bifurcation means off-the-shelf generation is simpler but users or tools can fully customize. The counts (14 genders, 21 ideologies, etc.) match those in the Identity Engine spec.
• Worldview detail: Every persona now includes a civic worldview with 21 ideology categories, 7 conviction levels, 6 engagement levels, and explicit stances on major issues (economy, liberties, environment, foreign policy, tech, etc.). Political identity is thus highly granular. Crucially, the summary reminds that these issue stances do not automatically imply traits or abilities – e.g. “Political identity affects priorities and interpretation, but should never imply intelligence, morality, competence, or temperament.” This mirrors the anti-stereotyping stance. The result is a persona with both ideology (e.g. “Green/Ecological, strength 78”) and policy opinions, which is more nuanced than a simple party label. This approach is consistent with contemporary political research showing many Americans hold mixed views across issues.
• Portrait & accessibility: The androgynous-portrait report (internal) is integrated here. The implementation summary describes how the portrait compiler uses its guidance: balanced feature language, neutral hair and clothing prompts, subdued color palettes, no explicit gender cues. It also enforces factual alt-text (using name or “they”). In effect, this is exactly the embodiment of the anti-bias portrait rules. These steps have analogs in UX design for inclusive imagery (e.g. avoiding heavily gendered elements). The reference to saving the report “byte-for-byte” indicates version control.

Methodology & Scope: This is a release note, not a study. It lists what was changed or enforced in code and data, including file lists. Its “data” are essentially the new counts and rule descriptions. There is no experiment or field data. The bias perspective is embedded in the text: for example, the remark about “default generation selects only man/woman” is a very specific design choice that could raise questions. Why not include ‘nonbinary’ in random choice? The text doesn’t justify it; further investigation (e.g. user studies or expert review) would be needed to validate that policy. Similarly, labeling 21 ideologies is a design decision – one might ask if that granularity matches real user models.

Corroboration & Context: The portal’s enactment of the androgynous portrait aligns with known accessibility guidelines (e.g. no gender guessing) and visual design discussions. The broad listing of identity categories aligns with LGBTQ+ resources that document many gender/pronoun types. The political details draw on public polling logic (e.g. classifying people by values, not party). The note that “engagement and strength don’t replace issue-level positions” reflects political science findings that even strong partisans vary on issues. The mention that no trait is inferred from demographics echoes common AI fairness wisdom. Thus, the implementation summary’s content is largely consistent with external best practices and research. We found no glaring contradictions.

Recommendations & Follow-up: One task is to verify that the new political worldview system is well-understood by AI: e.g. test outputs to ensure that a persona marked “Green/Ecological” with “strong” conviction indeed prioritizes environment-related content. Surveys or logs could be analyzed to see if the worldview fields shape dialogue as intended. The gender/orientation defaults should be examined: if random personas remain 50% male/female only, it may skew representation. If inclusivity is a goal, consider randomizing among nonbinary as well. Also, given the heavy emphasis on civics, it would be wise to include more global or non-Western ideologies if the user base is international. Finally, all new JS files and schemas listed should be code-reviewed and tested; automated tests could be added to catch any rule violations (e.g. persona must always have a shortPersonalitySummary).

Persona Memory and Restoration v20

• Eight-tier memory architecture: Persona memory is explicitly structured into eight categories: (1) Protected identity (core persona attributes like name, personality summary, career, etc.), (2) Relationship state (trust, respect, etc. in user relationship), (3) Active objective (current tasks and plans), (4) Working memory (temporary facts needed for tasks), (5) Episodic memory (events and outcomes with sources), (6) Semantic/user-approved facts (explicit, durable knowledge about the user/persona), (7) Unresolved threads (open questions, deferred promises), and (8) Archive/evidence (superseded records, provenance, rollback info). This tiered system mirrors cognitive memory theory: e.g. categories 4–6 correspond to standard working memory, episodic memory, and semantic memory. By labeling and separating them, the engine can manage each type differently.

• Restoration rules: The document specifies exactly which fields restore and how. For instance, identity.name always restores as a name (no role substitution), identity.title only as honorific, and shortPersonalitySummary/career remain distinct. Gender and orientation restore from the canonical state – they are never guessed from context. Civic worldview fields also restore individually. Portrait guidance (the textual prompts for images) restore only as metadata, and do not re-inject any hidden identity claims. These rules enforce fidelity: a persona’s core attributes can be loaded directly rather than inferred.

• Memory promotion and conflict handling: The plan details how memories are validated and updated. Key points include: user corrections override stale data; only explicitly encountered facts (from dialogue or reviewed imports) become memory; beliefs (especially political) can evolve only with explicit evidence; emotional states decay rather than reset each turn; conflicting info is quarantined until resolved. This is a careful, mostly conservative approach. It resembles scientific record-keeping: you never assume something without citation (“unproven memory is not treated as fact”); contradictory information is flagged.

• Restore order and tests: A strict read-order for restoration is given (first identity, worldview, then personal history, then voice/agenda, then relationship, etc.). There are also “acceptance tests” for a successful restore, such as matching schema version, fingerprint, distinct fields, consistent worldview constraints, no unverified facts, etc. These are essentially automated sanity checks to prevent loading corrupted or incompatible persona states.

Methodology & Bias: As a specification, this is design work, not experiment. It borrows concepts from psychology (short-term vs. long-term memory) and knowledge engineering (provenance tracking). The “promotion” rules embody a bias toward factual accuracy and user control: e.g. persona will not retain any memory unless the user has seen it, preventing the AI from inventing stuff about past unseen events. This leans on conservative memory policy (similar to enterprise knowledge management: don’t store rumor as fact). The potential downside is that it may under-utilize memory (overly cautious) and require lots of explicit user feedback.

Corroboration & Context: The memory tiers align with human memory models. The cited survey on AI memory describes working vs long-term (episodic/semantic) memory, which matches tiers 4–6. The idea of not inferring orientation from appearance connects back to the alt-text rule. The focus on user-provided corrections overriding previous memory is reminiscent of user-centered design (User says it, the system takes it). There is a parallel in AI agent literature: recent LLM agents (e.g. AutoGPT) also separate short-term vs long-term memory, although not as rigorously. We found no conflicting principles; most align with best practices (e.g. provenance-based knowledge bases).

Recommendations & Follow-up: It would be valuable to benchmark this memory system. For example, test conversation scenarios to see if important facts are retained correctly through the tiers. One could evaluate “memory recall accuracy” by simulating multi-turn chats and checking if the agent remembers facts (e.g. user’s name, preferences) properly. Also, monitor for memory clutter: do unresolved threads or archived history grow without limit? If so, pruning policies might be needed. Another follow-up is to assess user comfort: ensure users can easily correct or delete persona memory. Given this complexity, thorough logging and user transparency will be key (as implied by “reviewable imported state”). Automated tools could be developed to audit the memory database for consistency with the stated rules.

Deep Prompt Architecture v20

• Hierarchy of prompt layers: The system’s prompt compiler builds a layered conversational prompt. The “top of stack” explicitly includes identity and persona fields in order: 1) personal name and honorific, 2) personality summary, 3) career, 4) demographics (gender, pronouns, etc.), 5) worldview (ideology, strength, engagement, issues), 6) portrait/alt-text guidance, then 7) deeper persona elements (causal history, motivations, values, memory, examples, tests). This strict ordering ensures the LLM is first anchored in the character’s core identity. Such structured priming is more detailed than common role-play prompts; it resembles annotated system messages listing all persona attributes.

• Activation and execution flow: There is a 16-step activation sequence. Early steps restore the persona’s identity and worldview from seed, ensuring consistency. Subsequent steps apply motivations (drives, goals, stakes), then psychometrics (Big Five traits as continuous values), voice characteristics, reasoning style, affect/emotion baseline, relationship stance, and finally response-mode selection. The last steps include running internal “tests” (drift checks, memory consistency, etc.) and then generating the first-turn output in the requested mode. This design is unusually formal for prompt engineering; it reads like an agent architecture blueprint. It enforces that no response is ever generated without first reconstructing all relevant persona state.

• Per-turn loop: Each turn, the system follows a brief internal loop (invisible to user) to interpret the request, identify any changed context, choose a response mode (from 25 possibilities), generate output, then update memory under strict rules. It specifically prohibits “generic assistant filler” and invented memory, matching the anti-generic contract below. This is in line with modern LLM agent designs where the model self-critiques and adheres to persona guidelines each turn.

• Artifact outputs: The compiler produces multiple artifacts, each with a purpose: a full “system prompt” encoding the entire persona contract; a compact prompt (token-reduced kernel of identity and worldview); post-history instructions for drift resistance; as well as data artifacts (canonical JSON, Persona Seed, Character Card, Memory Capsule, .uai modules, etc.). This breadth ensures that every aspect (identity, memory, modes, tests) has a representation. The use of a separate memory capsule mirrors emerging LLM memory APIs (e.g. OpenAI’s “memory” endpoint).

• Anti-generic/anti-stereotype rules: A dedicated contract section lists hard rules for dialogue style. For example: “Enact traits rather than announcing adjectives” (don’t say “I am kind,” show kindness instead); “Do not open with generic greetings or setup questionnaires”; “Do not use demographics or ideology as shortcuts to personality traits”; “Do not force political commentary into unrelated tasks”; “Do not invent memories or user consent”. These are strong guardrails against cliché chatbot behavior. They reflect known persona prompt guidance (e.g. telling the assistant to avoid “It’s my pleasure to help” clichés).

Methodology & Bias: This is a comprehensive systems design, not a research experiment. It assumes that a highly structured, rule-driven prompt yields better persona fidelity. The bias here is towards control and consistency: every nuance is spelled out. Such rigidity can reduce creativity but increases predictability. One risk is verbosity: these many layers may exceed model context windows or slow response. The 25 response modes might help, but if contexts grow too large, performance could suffer. Another bias: the persona always “remains in character” – which may limit handling of novel topics.

Corroboration & Context: The multi-layer persona prompt echoes ideas from persona-based chatbot literature, but is more detailed than typical approaches. The step order aligns with best practices in role-playing (establish identity and goals first). The voice and reasoning guidelines (e.g. evidence-based reasoning, uncertainty) reflect known AI safety recommendations (don’t hallucinate facts). The rule “do not use protected attributes as a shortcut for traits” parallels fairness guidelines (echoing [5†L56-L64] and general anti-bias). The concept of an internal loop checking for compliance is used in advanced agent frameworks (similar to “output self-evaluation” in chain-of-thought literature). We found no external standard that mandates exactly this architecture, but the pieces individually match known advice for LLMs (e.g. specifying style and facts explicitly).

Recommendations & Next Steps: Given its complexity, this prompt architecture should be stress-tested. For example, run the system through edge-case dialogues to see if it ever violates the anti-generic rules (e.g. inadvertently uses a catchphrase). Automated compliance tests could simulate possible violations. The multitude of prompt artifacts suggests tooling might be needed to keep them in sync; an audit of the prompt generation code is recommended. Additionally, measuring effectiveness of “enact don’t announce” could involve a user study: does the persona feel more genuine? Finally, review context size: consider fallback strategies if prompts exceed token limits (the summary does mention “compact prompt” variants, which is good). Ensuring that memory and examples can be pruned or condensed without losing fidelity will be important.

Consolidated Synthesis

Consensus across reports: All documents strongly emphasize an explicit, user-driven persona identity. Gender, orientation, and demographic fields are always taken from provided data (never guessed), mirroring guidelines like “don’t assume gender”. Each report reaffirms that personal traits (name, summary, career) are distinct and not conflated. There is universal agreement that personality should be modeled dimensionally: the engine and prompt architecture apply continuous psychometric traits (Big Five) rather than crude categories, which matches psychological consensus. Memory and continuity are handled systematically: all agree on layered memory tiers and strict restoration rules (so that personas “remember” consistently between sessions). In summary, the reports converge on building a richly specified, coherent persona that is stable over time and resistant to drifting or stereotyping.

Metrics comparison: Key “counts” align. For example, both the Persona Wizard and Identity Engine cite 14 gender identities and 10 pronoun sets. The Implementation Summary confirms these and adds counts for orientations (17 sexual, 11 romantic) and worldview options (21 ideologies, 7 strength levels, 6 engagement levels). A quick summary table (from v20 data) is:

(Chart: Options per persona category in v20 — see below.)

graph LR
    Persona[Persona] --> Identity["Identity: name, gender, pronouns, etc."]
    Persona --> Worldview["Civic worldview: ideology, issues, rules"]
    Persona --> Portrait["Portrait guidance & alt-text rules"]
    Persona --> Memory["Memory tiers (relationship, events, etc.)"]
    Persona --> Behavior["Traits & values (psychometrics)"]

Disagreements & Gaps: There are few explicit conflicts, but some open questions emerge. The decision to randomize only male/female gender and default to straight/hetero is controversial: it introduces a heteronormative bias not substantiated by any rationale here. Surveys suggest significant minorities of users identify as nonbinary or LGBTQ+; randomizing among a broader set might better reflect that. Similarly, the worldview categories (21 ideologies) may reflect an internal taxonomy but lack justification; it would be useful to confirm these cover major real-world ideologies. Another gap is demographic breadth: race and religion are not included, perhaps intentionally to avoid stereotypes, but some use-cases might need them. Finally, while many safeguards are spelled out (“don’t infer X”), the enforcement of these depends on the system's ability to self-regulate, which should be empirically checked.

Corroborating Evidence: External sources generally support the design philosophies. The implementation’s stance on personalized naming and contextual relevance aligns with UX research advocating realistic, empathetic personas (e.g. psychology of character belief). The multi-ideology worldview reflects findings that public opinions are complex (Pew 2026 shows nine value-based groups). The memory framework echoes cognitive science categories. In no case did we find a cited design principle in these reports that contradicts mainstream guidance. On the contrary, many align with published guidelines: e.g. accessibility [5] and personality psychology.

Actionable Recommendations:

• Evaluate Defaults and Randomization: Re-examine the heteronormative defaults (binary gender, straight orientation). Consider user research or demographic data to justify or adjust these choices.
• User Testing: Conduct usability testing on the persona builder and outputs. For example, verify that persona descriptions using all the new fields feel coherent to end-users. Test how the androgynous portrait settings are perceived.
• Bias Audits: Given the emphasis on non-inference, run controlled tests to ensure no hidden bias leaks through. For instance, supply varied demographic profiles and confirm generated text does not attribute traits based solely on those.
• Performance Benchmarking: The prompt and memory architectures are complex; benchmark response times and token usage. Check if the 25 modes and large memory produce bloat. If needed, optimize (e.g. condense the “compact prompt” further or use embeddings).
• Expand & Validate Content Lists: Ensure the name pools, ideologies, honorifics, etc. remain updated and culturally broad. Gather data (e.g. census or naming statistics) to validate that the identity catalogs are representative.
• Monitor and Iterate: As these are systematic changes, we recommend logging persona statistics (gender distribution, orientation distribution, worldview usage, response modes) in real deployments to spot anomalies or drift. These analytics can guide refinements.

Overall, the v20 reports describe a highly structured, principled persona system that aligns with many external best practices. The next steps involve empirically verifying that this architecture works as intended in practice, and filling any gaps (especially around diversity and fairness).

Sources: The analysis above integrates information from the provided v20 design documents and external references. In particular, external guidance on alt-text/gender, personality trait modeling, romantic vs. sexual orientation, political typology, and human memory taxonomy were used to corroborate the reports’ claims. The cited literature supports the system’s emphasis on explicit identity fields, dimensional traits, and nuanced worldview.