# Personas and Actors A product may serve a database administrator, marketing analyst, warehouse operator, claims handler, support engineer, or another recognizable role. A role name offers useful orientation and may suggest how a user views the product, but it rarely gives a delivery team enough context to understand how that person actually works. For example, two database administrators may have different responsibilities, operating environments, decision rights, workloads, exposure to failure, and reasons for using the same product. Specification-First Delivery records those material differences as governed product knowledge. Within the [Shared Knowledge System](/en-us/hub/shared-knowledge-system), an **Actor** identifies a human role or operational capacity through which a person interacts with or materially affects the product. An **operational persona** (or just a persona) represents a materially different class of people who may perform one or more Actor roles, preserving the goals, responsibilities, authority, working conditions, constraints, and current operational state needed to reason about their product needs. Personas have long been used to carry richer user knowledge into software design, while role-based requirements research has shown why one homogeneous role can hide meaningful differences between the people who occupy it.[^citation-01][^citation-02] Operational personas also have a lifecycle. They combine a relatively stable persona core with an evolving operational state. For example, a database administrator may remain responsible for database reliability even as the work changes: - Before delivery changes the workflow, the database administrator may manually check replication-delay dashboards and contact a provider during every incident. - After the product automates the response, upstream data-feed issues trigger emails to vendors and notifications to affected users. The database administrator remains responsible for database reliability but can focus on other work instead of routine incident coordination. The operational state recorded in the persona should change with that reality. Responsibilities, recurring interventions, pain points, escalation paths, and even the reason a particular persona exists can all be affected. AI-assisted engineering makes this lifecycle increasingly practical. Data-driven persona research has progressively used analytics and software to construct and maintain persona knowledge. Later studies proposed using feedback and monitoring data for persona creation, validation, and evolution; extracted behavior and pain points from B2B software logs with generative AI; and demonstrated continuous persona generation with large language models and knowledge graphs for requirements engineering.[^citation-03][^citation-04][^citation-05][^citation-06] Specification-First Delivery connects these capabilities to governed delivery. AI can help find affected personas, retrieve relevant sources, compare the recorded state with current operations, draft candidate changes, and route the work through Governing Instructions or a persona-focused Skill. The same division of labor can begin at persona creation: when Product Intent, existing specifications, specialist knowledge, and current operational knowledge are already available, an AI coding agent can synthesize candidate persona knowledge while people concentrate on deciding what is true, material, current, and authoritative. The people or functions responsible for the represented operating reality retain authority over material changes. The practical model developed in this guide covers five connected concerns. 1. **Human operating model** Actors identify roles and capacities; operational personas preserve materially different ways in which people perform those roles. 2. **Persona evolution** A relatively stable persona core is maintained alongside an evolving operational state that can change when delivery changes real work. 3. **Persona-guided discussion** Structured discussion can load applicable personas so requirements are examined against recorded goals, constraints, responsibilities, authority, and pain points. 4. **Context routing** A persona library makes records discoverable, while Governing Instructions and optional Skills can route humans and AI to the personas relevant to the current decision. 5. **AI drafting and human confirmation** AI can synthesize candidate persona records and routing knowledge from authoritative product context; represented practitioners and decision owners confirm consequential statements before downstream delivery relies on them. [Product Intent](/en-us/hub/product-intent) provides the product-level statement of purpose, outcomes, priorities, and scope. Operational personas describe the people and operating conditions that shape how that intent is experienced. Stable Use Cases describe recurring purposes and interactions those people need the product to support. Keeping these layers connected lets a later participant see what the product is trying to achieve, who is affected, and which operating context changes the interpretation of a requirement. ## 1. Actors and Operational Personas An Actor is a human role or operational capacity that matters to product behavior. It answers questions such as who operates the product, who approves a material action, who responds when a process fails, who supplies professional judgment, and who is permitted to perform a class of work. One person may act through several capacities. A database administrator may be an ordinary operator during routine work, an incident responder during a production failure, and a change approver during a database migration. The Actor definition makes those capacities and their authority visible while leaving person-specific operating differences to the applicable personas. An operational persona adds those differences when they can change requirements, workflow, product behavior, permissions, operational support, or acceptance. Miller and Williams make a similar observation in role-based requirements engineering: a role presents a relatively homogeneous view, while different types of users within that role may require a deeper representation.[^citation-02] For example, an organization may have a `Database Administrator` Actor while maintaining several operational personas: - **Alex, Database Performance DBA** focuses on query performance, replication behavior, index health, capacity, and production incidents across large database estates. - **Priya, Cloud Database Infrastructure DBA** focuses on managed database services, infrastructure configuration, patching, cloud networking, access, and platform-level resilience. - **Chen, Data Platform Operations DBA** focuses on ingestion health, upstream data-provider failures, data freshness, recovery, and operational communication with downstream users. The names are optional identifiers intended to make discussion easier. They are especially useful when several personas share the same broad job title because a team can refer to a specific operational specialization without repeatedly restating its full description. The operating differences behind the name define the persona; biographical detail belongs only where it changes product reasoning. A single operational persona can participate through several Actors, and one Actor can be represented by several operational personas. This many-to-many relationship keeps the product model aligned with materially different ways of working even when the organization uses one job title for all of them. ```mermaid flowchart LR accTitle: Actors and operational personas form a many-to-many relationship accDescr: One operational persona may act through several human capacities, while one Actor role may be performed by several materially different operational personas. P1[Alex: Database Performance DBA] P2[Priya: Cloud Database Infrastructure DBA] P3[Chen: Data Platform Operations DBA] A1[Database Administrator] A2[Incident Responder] A3[Change Approver] P1 --> A1 P1 --> A2 P1 --> A3 P2 --> A1 P2 --> A3 P3 --> A1 P3 --> A2 ``` ## 2. Operational Persona Content An operational persona should preserve the information that materially changes product reasoning. Biographical details such as age, photograph, hobbies, or family status belong in the record when they genuinely affect the product. Operational characteristics receive the same test: retain them when they can change a decision, requirement, workflow, constraint, or acceptance condition. Research on persona practice supports this emphasis. A 2023 systematic mapping study reviewed 78 relevant requirements-engineering studies and found personas used to support stakeholder understanding, human-centered requirements work, and requirements-engineering activities, while also identifying creation, validation, and incorporation challenges.[^citation-07] A useful operational record therefore preserves the material persona statements needed for delivery decisions rather than treating the persona as presentation material. Specification-First Delivery organizes operational persona knowledge into three areas. 1. **Stable persona core** Records the relatively durable identity of the persona, including Actor roles, expertise, recurring goals, enduring responsibilities, decision authority, recurring dependencies, durable constraints, and success conditions. 2. **Evolving operational state** Records how this persona currently works, including workflow, workload and scale, activity frequency, tools, information sources, manual interventions, on-call responsibilities, failure conditions, workarounds, automation level, and current pain points. 3. **Ownership and governance** Records the accountable owner, contributors, review status, last review, unresolved questions, and material change history needed to keep the persona authoritative. The stable core changes relatively infrequently because it describes why the persona remains a recognizable operational class. The evolving operational state moves more often as product delivery, organizational change, automation, regulation, tooling, scale, and operating experience alter the work itself. A useful record may include the following fields. > **A substantial template can become a guided conversation** > > This template may look intimidating, but an AI coding agent can turn it into a structured interview and work through each field with you. The agent asks focused questions, draws on existing product knowledge, and drafts the content for review; the people responsible for the represented work decide what is accurate, material, and authoritative. [Requirements, Structured Discussion, and Increments](/en-us/hub/requirements-increments-and-structured-discussion) explains the structured-discussion model behind this collaboration. ```text Persona ID: Display name: Summary: Actor roles and capacities: Relevant expertise: Recurring goals: Recurring responsibilities: Decision authority: Recurring dependencies: Durable constraints: Success conditions: Current workflow: Current scale and workload: Frequency and timing: Tools and information sources: Manual interventions: On-call or escalation responsibilities: Current failure conditions: Current workarounds: Current pain points: Current automation level: ``` Teams select the fields that materially affect the persona. A small product may need only a short paragraph for each material user class. A complex operational product may need detailed records because differences in timing, permissions, scale, failure response, or professional authority directly affect delivery decisions. ## 3. Example: A Database Performance Persona Consider an internal data platform whose database operations team manages approximately 2 PB of production data. One operational persona might be recorded as follows: ```text Persona ID: dba-database-performance Display name: Alex Summary: Senior database performance engineer responsible for production database performance and first-line diagnosis of replication and data-availability incidents. Actor roles and capacities: - Database Administrator - Production Incident Responder - Database Change Reviewer Relevant expertise: - Query and index performance - Replication behavior - Capacity and storage growth - Production failover and recovery Recurring goals: - Keep production data available and sufficiently current for downstream users. - Diagnose material performance and replication degradation quickly. - Apply database changes without creating avoidable production risk. Decision authority: - May initiate approved operational recovery procedures. - May approve routine database changes within delegated policy. - Escalates product, provider-contract, or architecture decisions to their owners. Current operational state: - Participates in primary on-call rotation approximately every two weeks. - Reviews replication delay, storage growth, backup health, and cluster alerts. - Manually correlates replication lag with deployment, provider, and network events. - Contacts the upstream data provider when delayed or malformed data is suspected. - Communicates material data freshness issues to affected downstream users. Current pain points: - Replication dashboards do not connect lag with likely upstream causes. - Provider notification is manual and frequently begins after the DBA has already performed initial diagnosis. - Downstream users rely on the DBA to communicate whether stale data is safe to use. ``` The scale, on-call frequency, decision authority, and manual incident workflow all matter to product design. A feature that looks useful for a generic DBA may be unsuitable if it adds another dashboard to check during an incident, hides information required for an approval decision, or assumes the DBA can wait for a synchronous workflow while supporting production. The persona also makes improvement observable. The product team can identify which operational burden it intends to remove and later test whether delivery actually changed that burden. ## 4. Persona Evolution Through Delivery Operational personas describe current work, so successful delivery can change them. This is a deliberate part of the Knowledge System lifecycle and one of the main reasons Specification-First Delivery treats personas as current-state knowledge rather than a one-time design artifact. The research trajectory supports making persona maintenance a continuous engineering concern. A survey of 77 data-driven persona studies describes the increasing use of online user data, analytics, and software in persona development.[^citation-03] Patkar and Seyff propose using user feedback and monitoring data to create, validate, and evolve personas.[^citation-04] In B2B software, Sera et al. combine clickstream data, clustering, and generative AI to derive user behavior and pain points, directly addressing the need to revise personas for an existing service.[^citation-05] Sugiyama et al. go further by proposing continuous data-driven persona generation with large language models and knowledge graphs, explicitly linking persistent persona updates to the software development lifecycle.[^citation-06] Specification-First Delivery adds a delivery trigger and governance path to those capabilities. An accepted increment can change the operating reality represented by a persona. After delivery, the team therefore examines more than software conformance: it also asks whether the change altered a responsibility, recurring intervention, pain point, decision path, tool dependency, or other persona knowledge that future work will rely on. [Knowledge Convergence Across the Increment Lifecycle](/en-us/hub/knowledge-convergence-across-the-increment-lifecycle) provides the broader mechanism for returning material delivery learning to the Knowledge System under appropriate authority. Suppose a reliability increment changes the database incident path described above. The platform now detects a defined class of upstream data failure, sends the provider a structured diagnostic report automatically, marks affected data as stale, informs downstream users through an authoritative status channel, and escalates to the DBA only when automated recovery or provider response fails. Once the change is accepted and the operational effect is confirmed, Alex's persona should reflect a different day-to-day reality. Provider notification is no longer part of the normal manual response, and downstream users no longer depend on Alex for routine freshness communication. First-line intervention for this failure class becomes an exception, reserved for cases that automation or the provider cannot resolve. If the same operating model later covers a broader set of failures, the on-call burden itself may shrink or move to another role. That update is part of knowledge convergence. Future requirements should start from the new operating reality, not from work the product has already removed. **Persona evolution: From current operating reality to reviewed current-state knowledge** 1. **Record current operational state** Maintain the stable persona core together with the current workflow, workload, constraints, interventions, and pain points that materially affect product decisions. 2. **Use persona context in delivery** Load the applicable persona during structured discussion and specification so the proposed increment is examined against how the relevant people actually work. 3. **Observe the delivered operating change** After delivery, use observed operating conditions and accountable participants to determine whether responsibilities, frequency, tools, pain points, or escalation paths actually changed. 4. **Review and update the persona** Update current-state persona knowledge under the authority appropriate to the affected responsibility, and review dependent use cases or requirements when the change alters their assumptions. ### 4.1. AI-Assisted Persona Evolution AI-assisted engineering can make this lifecycle easier to maintain because source review, comparison, and routing can be repeatable. In a repository-centered implementation, Governing Instructions can require a persona-impact review when an accepted increment materially changes a user workflow, responsibility, permission, support path, or pain point. A persona-focused Skill can then define how to find the affected records, gather the applicable current knowledge, compare the documented persona with the accepted product state, draft candidate edits, and identify dependent use cases or specifications that may also need review. Much of that preparation is suitable for AI. An agent can inspect the incident records or approved operational summaries available to it, compare before-and-after workflows, draft a persona diff, flag recorded details that have become stale, and identify a possible split, merge, or retirement. Monitoring data and user feedback can reveal further changes, reflecting the data-driven evolution approaches described in the research above.[^citation-04][^citation-05][^citation-06] The result is a proposed Knowledge System change. Routine factual maintenance can follow the normal review path for the source. Changes to recurring responsibilities, decision authority, major operating conditions, defining goals, Actor relationships, or persona lifecycle state go to the people or functions whose authority is affected. AI reduces the friction of keeping the persona current; it does not inherit the authority represented by the persona. Over time, the library itself can change shape. Platform automation might erase the workflow that once justified two separate database personas, allowing those records to converge. Expansion into a regulated operating context may create a new specialist persona. If a role leaves the operating model altogether, its persona can be retired while its historical delivery records remain available where needed. The approval threshold follows consequence rather than field location. Updating an observed database scale from 1.8 PB to 2.0 PB may be routine factual maintenance. Removing an on-call responsibility changes the operating model and therefore needs review by people with authority over that responsibility, even though both statements sit inside the evolving operational state. ## 5. Persona-Guided Structured Discussion Operational personas become most useful when they are directly available to [structured discussion](/en-us/hub/requirements-increments-and-structured-discussion). A requirement can then be examined from the recorded operating context of each materially affected persona before downstream specifications depend on an assumed user model. A practical discussion sequence is: 1. identify the human Actors affected by the requirement; 2. locate the operational personas that materially differ within those Actor roles; 3. load only the persona records relevant to the current question; 4. examine the proposed outcome against each persona's goals, responsibilities, authority, constraints, workflow, failure conditions, and current pain points; 5. surface conflicting needs, missing scenarios, changed responsibilities, unsupported assumptions, or knowledge gaps; 6. route material decisions and persona changes to the appropriate human authority; and 7. preserve reviewed conclusions in the discussion record and any specifications that follow. For the database example, an AI participant could review a proposed maintenance workflow from Alex's current operating context and look specifically for changes to on-call responsibilities, information needed during an incident, approval decisions, or escalation paths. Repeating the exercise with Priya's cloud-infrastructure persona can reveal a different set of concerns even though both personas share the Database Administrator Actor. The persona supplies reasoning context. It remains a governed organizational record whose material interpretations and changes follow the applicable human authority. > **Persona simulation can uncover questions but cannot confer stakeholder authority** > > AI can reason from approved persona knowledge to identify scenarios, tensions, missing context, and possible consequences. Material interpretations, changes to persona knowledge, and decisions within a person's professional authority remain subject to the accountable human review path. Research on large language models supports keeping that authority explicit. Aher, Arriaga, and Kalai showed that language models could reproduce some established human-subject-study findings under simulated participant conditions, while also identifying systematic distortion in another experiment.[^citation-08] Persona-guided AI discussion is therefore useful for generating questions and testing interpretations against recorded context. The represented people and accountable functions familiar with the operating environment must confirm claims about how people actually behave or decide. ## 6. Persona Library and Progressive Context Loading A Knowledge System needs a discoverable way to locate applicable personas. The **persona library** is the maintained set of operational personas, Actor relationships, ownership, status, and routing information needed to retrieve the right human context for a delivery question. The storage pattern should remain proportionate. A small application with two or three uncomplicated user classes may keep the complete library in one `docs/personas.md` file. Once the product has personas with different owners, review histories, or applicability, separate records become easier to maintain and easier to load selectively. ## 7. Persona Skill as a Progressive Context Router A complex persona library benefits from a small routing layer. A persona Skill can summarize the available personas closely enough for an AI participant to choose the relevant records before loading them. The summary should contain applicability, not a duplicate of the full persona. This makes the Skill a directory and procedure, while `docs/personas/*.md` remains the source of authoritative persona knowledge. For the database example, a `skills/persona-directory/SKILL.md` could look like this: ```md --- name: persona-directory description: Route product and delivery work to the applicable operational personas. --- # Persona Directory Use this Skill when product, workflow, requirement, specification, or post-delivery review work may affect how a person performs an operational role. ## Persona index - `dba-database-performance` – Alex, Database Performance DBA - Load: `docs/personas/alex-database-performance-dba.md` - Use for: query performance, replication, capacity, database incidents, on-call response, and database-change review. - `dba-cloud-infrastructure` – Priya, Cloud Database Infrastructure DBA - Load: `docs/personas/priya-cloud-database-infrastructure-dba.md` - Use for: managed database services, cloud networking, patching, access, infrastructure configuration, and platform resilience. - `dba-data-platform-operations` – Chen, Data Platform Operations DBA - Load: `docs/personas/chen-data-platform-operations-dba.md` - Use for: ingestion health, upstream provider failures, data freshness, recovery, and downstream operational communication. ## Loading procedure 1. Identify the affected Actor roles and operating concerns. 2. Match those concerns against the persona index. 3. Load only the persona records that can materially change the decision. 4. If no persona covers a material operating context, record the gap and route it to the product or domain owner before relying on an assumed user model. 5. If two applicable personas conflict, preserve both contexts and route the decision to the authority responsible for the affected requirement. ## Post-delivery persona review When accepted delivery changes a workflow, recurring responsibility, permission, support path, intervention frequency, or pain point: 1. reload the affected persona records; 2. compare the recorded operational state with the accepted delivery outcome; 3. draft candidate persona changes and identify dependent use cases or requirements; 4. route material changes to the people or functions whose authority is affected; 5. update the authoritative persona only after the required review. ``` The index is intentionally compact. If the work concerns replication lag and production incident response, the agent can select Alex before loading any detailed persona file. A cloud-networking change points to Priya. An upstream data-provider failure points to Chen. Some work will need more than one persona, but the agent starts from a few short routing descriptions instead of placing the full persona library into every context window. Governing Instructions and the Skill have different jobs. Governing Instructions can make persona consideration mandatory for relevant classes of work and can require post-delivery persona review when accepted changes alter operating reality. The Skill supplies the reusable routing and maintenance procedure. This combination implements [Progressive Context Loading](/en-us/hub/shared-knowledge-system): mandatory instructions stay small, the persona index is loaded when the work needs human operating context, and full persona records enter context only when their applicability has been established. In this repository-centered example, `skills/persona-directory/` is the maintained root Skill. A repository may expose the same Skill through symlinks or equivalent compatibility paths when different coding agents expect different discovery locations. [Knowledge System Readiness for Specification-First Delivery](/en-us/hub/knowledge-system-readiness-for-specification-first-delivery) owns the broader repository setup and single-source routing pattern; this guide keeps the structure focused on the persona knowledge itself. - `product/`: Focused repository example showing the authoritative persona records and the persona routing Skill. - `docs/`: Governed product knowledge used by delivery work. - `personas/`: Authoritative operational persona records. - `alex-database-performance-dba.md`: Database performance, replication, capacity, production incidents, and database-change review. - `priya-cloud-database-infrastructure-dba.md`: Managed database infrastructure, cloud networking, patching, access, and platform resilience. - `chen-data-platform-operations-dba.md`: Ingestion health, upstream data-provider failures, data freshness, recovery, and downstream operational communication. - `skills/`: Reusable Skills maintained at the repository root. - `persona-directory/`: Persona routing and maintenance procedure. - `SKILL.md`: Persona index, loading rules, gap handling, conflict routing, and post-delivery review procedure. Each persona file remains authoritative for the operating context it records. The root Skill supplies the routing and maintenance procedure; agent-specific discovery wiring stays outside this persona-focused view. A document repository, product-management platform, knowledge graph, or another maintained system can implement the same capability. The framework requirement is discoverable, governed persona knowledge with a reliable way to select the records relevant to the current decision. Markdown files and a persona routing Skill are one repository-centered implementation of that capability. ## 8. AI Drafting and Line-by-Line Human Confirmation A detailed persona system is a strong candidate for AI-assisted authoring. If [Product Intent](/en-us/hub/product-intent), existing requirements, specialized specifications, architecture and operational knowledge, the current implementation state, and user research already exist, an AI coding agent can synthesize more recorded context at once than any one participant is likely to recall in a blank-page exercise. This changes where human effort is most valuable. The practical starting point becomes a structured discussion with the agent, followed by disciplined review from the people who hold authority over the resulting statements. Research already supports the underlying division of labor. Shin et al. found that persona generation improved when human experts identified the important characteristics and user groupings while LLMs summarized the resulting evidence into personas; that collaborative workflow produced personas that were more representative and empathy-evoking than either human-only or LLM-only approaches in their study.[^citation-09] More recently, Amini et al. evaluated an agentic critique-refinement approach at Kinaxis. Domain experts approved 96.9% of PerGent-generated persona content unchanged, and the generated personas also contributed useful, non-redundant content beyond personas that domain experts had written before LLM adoption.[^citation-10] These results support using AI for synthesis and drafting while keeping human expertise central to validation. Specification-First Delivery extends that pattern into the governed Knowledge System. The AI coding agent can begin by loading the authoritative product knowledge already available, then propose the Actor map, candidate persona boundaries, full persona records, knowledge gaps, and the persona-directory Skill that routes later work. Existing specifications are especially valuable inputs because they contain decisions that a blank-page persona workshop may fail to recall: permissions, failure behavior, specialist obligations, rejected assumptions, operational constraints, and terminology that already shape how people use the product. A practical authoring sequence is: 1. load Product Intent, existing user research, applicable Stable Use Cases, current and specialized specifications, relevant architecture or operational records, and the current implementation state; 2. ask the coding agent to propose the Actor relationships and persona set, explaining which differences are material and identifying contradictions or missing information; 3. have the agent draft the complete persona records and persona-directory Skill, highlighting consequential statements for human confirmation; 4. perform **line-by-line confirmation** with the human Actors whose work is represented and the decision owners whose authority is implicated; and 5. make the reviewed records authoritative, then allow later structured discussion and specification work to consume them. Line-by-line confirmation is deliberately more demanding than a general document approval. Practitioners should confirm workflow, workload, interventions, escalation paths, pain points, and other statements about how the work actually happens. Product and domain owners confirm product interpretation and the persona distinctions the product should rely on. Security, reliability, compliance, accessibility, architecture, or other specialists confirm statements within their professional authority. A material disagreement stays visible until the appropriate decision owner resolves it. The router deserves the same discipline. A wrong sentence in `persona-directory/SKILL.md` can prevent an applicable persona from ever entering the context of a later requirement. Its summaries, `Use for` rules, gap handling, conflict routing, and post-delivery review triggers should therefore be confirmed against the same authority model as the records they route. > **Complex templates shift effort from authoring to review** > > AI can draft detailed candidate content from existing product knowledge, turning a rich persona template into a review task instead of a blank-page authoring exercise. Human effort is better spent deciding, line by line, whether each consequential statement is accurate, current, material, and confirmed by the right authority. Specification-First Delivery combines authoritative seed knowledge, AI-assisted synthesis, Progressive Context Loading, and line-by-line human confirmation in a single operating model. The principle **Micromanage Specifications, Not Code** applies one layer upstream: persona records and the router Skill are governed product knowledge rather than specifications themselves, but they are part of the material from which requirements and specialized specifications are formed. The introductory [Specification-First Delivery](/en-us/hub/specification-first-delivery) paper describes knowledge as the material from which a specification is formed. An unchecked persona assumption can therefore propagate into several downstream specifications and then into generated implementation; confirming that knowledge before propagation is a higher-leverage control than discovering the mistake in code. ## 9. Relationship to Stable Use Cases and Specialized Specifications Operational personas and Stable Use Cases answer connected questions at different levels. A persona describes a materially distinct class of people and the operating reality that shapes their decisions. A Stable Use Case describes a recurring purpose or interaction the product must continue to support as individual features and implementations change. Alex's persona may state that he participates in on-call operations and currently diagnoses replication failures manually. A Stable Use Case may state that an authorized operator must investigate and respond to a material replication problem. Automation can remove Alex's manual diagnosis steps while leaving the higher-level use case recognizable. If the product later removes human first-line response altogether, the use case itself may need review. The relationship is many-to-many. One persona can participate in several Stable Use Cases, and one Stable Use Case can involve several personas with different constraints or authority. Structured discussion should load the combination relevant to the requirement instead of embedding every persona detail into every use case. The forthcoming Stable Use Cases paper will examine this relationship in greater depth. ## 10. Authority and Maintenance Persona quality depends on accurate, material, and current knowledge. Interviews, observation, support records, operational metrics, incident reviews, access models, workflow documentation, product analytics, surveys, and domain specialists can all contribute, depending on the persona. The accountable product or domain owner should be able to explain why each material statement belongs in the current record. A persona library must remain open to challenge and correction. Matthews, Judge, and Whittaker interviewed 14 experienced user-centered-design practitioners and found that personas in the organization studied were used mainly for communication rather than direct design work; participants also described personas as potentially abstract, impersonal, misleading, or distracting, and the authors concluded that personas cannot replace immersion in actual user data.[^citation-11] The authority model should therefore let a later participant challenge a questionable statement and route it to the people responsible for the represented operating reality. Authority follows the subject being changed: - Product and domain owners normally establish which personas materially represent the product's users and operating participants. - Operational leaders and practitioners confirm responsibilities, workflows, escalation paths, workload, and current pain points within their area. - Security, privacy, reliability, accessibility, compliance, or other specialists confirm statements that fall under their professional authority. - Engineers and AI participants can expose contradictions between persona knowledge and observed implementation or operating conditions; the appropriate decision owner confirms any material change to the affected responsibility. Routine factual maintenance can follow the normal review path for the source. A change to recurring responsibility, decision authority, major operating conditions, a persona's defining goals, its relationship to an Actor, or its split, merge, or retirement needs review from the people or functions whose authority is affected. ## 11. Proportionality and Validation A persona library should preserve the differences that can materially change product behavior, requirement interpretation, workflow, authority, permissions, constraints, operational response, or acceptance. Those differences justify separate operational personas; other characteristics can remain outside the product model unless they become relevant to a later decision. For a simple application, one `personas.md` file may be sufficient for the life of the product. As the application grows, that file can become an index or evolve into a `personas/` directory when separate records, owners, review histories, or AI loading rules improve maintainability. A persona Skill becomes useful when design and delivery work needs repeatable applicability rules across many personas or when persona evolution needs a repeatable post-delivery review procedure. The Knowledge System can adopt each additional layer when the product creates a concrete need for it. A practical validation is to give the relevant persona record to a qualified participant with no prior product history and ask whether they can determine: - what this class of person actually does; - which Actor roles and operational capacities apply; - what decisions the persona can make or approve; - which working conditions, constraints, scale, and frequency materially shape the work; - which information and other participants the persona depends on; - which current pain points or manual interventions still exist; - which parts of the record describe the relatively stable persona core and which describe current operational state; - who can confirm a material change. The participant should then be able to apply the persona to a representative requirement and identify the questions that must be resolved before implementation depends on an assumed user model. Passing that test means the persona is usable product knowledge: specific enough to shape delivery, current enough to describe how people work today, and governed strongly enough that future human and AI participants can rely on it while preserving the authority of the people the knowledge represents. [^citation-01]: Pruitt, J., & Grudin, J. (2003). *Personas: Practice and Theory*. Proceedings of the 2003 Conference on Designing for User Experiences, 1–15. [Microsoft Research](https://www.microsoft.com/en-us/research/publication/personas-practice-theory/). [^citation-02]: Miller, G., & Williams, L. (2006). *Personas: Moving Beyond Role-Based Requirements Engineering*. North Carolina State University Department of Computer Science Technical Report TR-2006-24. [NCSU Libraries](https://repository.lib.ncsu.edu/items/8617c98d-86e8-48b7-8689-53d46b4fba1f). [^citation-03]: Salminen, J., Guan, K., Jung, S. G., & Jansen, B. J. (2021). *A Survey of 15 Years of Data-Driven Persona Development*. International Journal of Human-Computer Interaction, 37(18), 1685–1708. [DOI](https://doi.org/10.1080/10447318.2021.1908670). [^citation-04]: Patkar, N., & Seyff, N. (2023). *Data-Driven Persona Creation, Validation, and Evolution*. Requirements Engineering: Foundation for Software Quality, 262–271. [DOI](https://doi.org/10.1007/978-3-031-29786-1_18). [^citation-05]: Sera, R., Washizaki, H., Chen, J., Fukazawa, Y., Taga, M., Nakagawa, K., Sakai, Y., & Honda, K. (2024). *Development of Data-driven Persona Including User Behavior and Pain Point through Clustering with User Log of B2B Software*. Proceedings of the 2024 IEEE/ACM 17th International Conference on Cooperative and Human Aspects of Software Engineering, 85–90. [DOI](https://doi.org/10.1145/3641822.3641870). [^citation-06]: Sugiyama, R., Washizaki, H., Ubayashi, N., Tanahashi, R., Hirabayashi, M., Okuda, S., & Toriumi, K. (2025). *Continuous Data-driven Personas Generation: An LLM-based Knowledge Graph Approach*. Proceedings of the 2025 IEEE 33rd International Requirements Engineering Conference, 561–569. [DOI](https://doi.org/10.1109/RE63999.2025.00067). [^citation-07]: Karolita, D., McIntosh, J., Kanij, T., Grundy, J., & Obie, H. O. (2023). *Use of Personas in Requirements Engineering: A Systematic Mapping Study*. Information and Software Technology, 162, 107264. [DOI](https://doi.org/10.1016/j.infsof.2023.107264). [^citation-08]: Aher, G. V., Arriaga, R. I., & Kalai, A. T. (2023). *Using Large Language Models to Simulate Multiple Humans and Replicate Human Subject Studies*. Proceedings of the 40th International Conference on Machine Learning, PMLR 202, 337–371. [PMLR](https://proceedings.mlr.press/v202/aher23a.html). [^citation-09]: Shin, J., Hedderich, M. A., Rey, B. J., Lucero, A., & Oulasvirta, A. (2024). *Understanding Human–AI Workflows for Generating Personas*. Proceedings of the 2024 ACM Designing Interactive Systems Conference, 757–781. [DOI](https://doi.org/10.1145/3643834.3660729). [^citation-10]: Amini, M. H., Dewar, D., Nejati, S., & Sabetzadeh, M. (2026). *Agentic Persona Generation with Critique-Refinement: An Industrial Evaluation*. 2026 IEEE 34th International Requirements Engineering Conference, Industrial Innovation Track. [arXiv](https://arxiv.org/abs/2606.09637). [^citation-11]: Matthews, T., Judge, T. K., & Whittaker, S. (2012). *How Do Designers and User Experience Professionals Actually Perceive and Use Personas?* Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 1219–1228. [DOI](https://doi.org/10.1145/2207676.2208573).