RCP-000-000-081-STAKEHOLDER-PERSONA-BUILDER

Business team discussing project strategies in a modern conference room.
A diverse group of professionals collaborating during a team meeting at CraftFramework.ai.

Every claim in every persona is tagged with its evidence source โ€” research-backed, your direct knowledge, or role-based inference

Attach your Stakeholder Map and paste your Deep Research findings. The AI matches research to stakeholders, then builds each persona one at a time. You review, correct, and validate each persona individually before the AI moves to the next. Once all personas are confirmed, you receive a single Persona File ready for RCP-082.


Stakeholder Persona Builder

Tags: stakeholder personas, evidence tagging, Deep Research, multi-recipe workflow, persona construction

TL;DR

What It Does
Takes your Stakeholder Map from RCP-080 and your Deep Research findings, then builds structured personas for each prioritized stakeholder. Every claim in every persona is tagged with its evidence source — research-backed, your direct knowledge, or role-based inference. The output is a self-contained Persona File you carry into the Discussion Simulator (RCP-082).
How To Use It
Attach your Stakeholder Map and paste your Deep Research findings. The AI matches research to stakeholders, then builds each persona one at a time. You review, correct, and validate each persona individually before the AI moves to the next. Once all personas are confirmed, you receive a single Persona File ready for RCP-082.
When To Use It
After completing the Stakeholder Discovery Engine (RCP-080) and gathering Deep Research findings. This recipe is the second step in a 4-recipe Stakeholder Analysis Workflow (080 → 081 → 082 → 083). You can also use it standalone if you bring your own stakeholder list and research findings.
Typical Time
30–60 minutes (varies by number of personas and depth of research findings).

How To Start

This is a construction workflow with one-at-a-time validation. The AI builds each persona from your evidence, you review and correct it, and then the AI moves to the next. Every factual claim is tagged with its evidence source so you always know what is research-backed and what is inference.

STEP 1Provide Your Inputs

Attach your Stakeholder Map from RCP-080 and paste your Deep Research findings. If you skipped Deep Research, you can proceed with your own knowledge — the recipe adjusts to work with whatever evidence you have.
Available parameters
  • stakeholder_map · text · required
    The Stakeholder Map from RCP-080 (or equivalent), containing topic summary, confirmed stakeholders, knowledge gaps, and persona count.
  • dr_findings · text · optional
    Deep Research findings. If DR was skipped, leave empty — the recipe adjusts to work with your direct knowledge only.
  • additional_knowledge · text · optional
    Any supplementary information about stakeholders not captured in the Stakeholder Map or Deep Research findings.
Example invocations
Full workflow (with Deep Research findings)
#H->AI::Directive: (Execute Stakeholder Persona Builder with stakeholder_map: [attach Stakeholder Map from RCP-080] dr_findings: [paste Deep Research findings])
Skip-DR path (user knowledge only)
#H->AI::Directive: (Execute Stakeholder Persona Builder with stakeholder_map: [attach Stakeholder Map from RCP-080])
Standalone (without RCP-080)
#H->AI::Directive: (Execute Stakeholder Persona Builder with stakeholder_map: We are considering a 4-day work week. Key stakeholders: VP Finance (budget authority), VP People Ops (retention advocate), Engineering Director (implementation), Client Success Lead (coverage). additional_knowledge: Our CFO has publicly stated cost neutrality is non-negotiable.)

STEP 2Confirm Research Intake

The AI presents a summary showing how your research findings map to each stakeholder. Review that the matching is correct and add any findings the AI may have missed or mismatched. If you skipped Deep Research, the AI acknowledges this and notes that personas will rely more heavily on your direct knowledge and role-based inference.

STEP 3Validate Each Persona

The AI builds one persona at a time using a 14-field template. Each persona includes role context, decision criteria, known positions, concerns, communication style, influence level, red lines, and flexibility zones. Every claim is tagged: [DR-SOURCED] for research findings, [USER-PROVIDED] for your knowledge, or [HYPOTHETICAL] for role-based inference. Review each persona, correct anything inaccurate, and add information the AI may have missed.

STEP 4Receive Your Persona File

Once all personas are validated, the AI assembles a single Stakeholder Persona File containing all personas, an evidence source legend, a recommended discussion format for RCP-082, and preparation notes identifying key tensions, likely alliances, and suggested opening topics for simulation. Copy or save this file to attach to your Stakeholder Discussion Simulator (RCP-082) chat session.

Usage Examples

Two scenarios showing how the Stakeholder Persona Builder works in practice. The first uses the full workflow with Deep Research findings; the second shows the skip-DR path for users with existing stakeholder knowledge.
Example 1 · Full workflow — building personas from DR findings
User: [Attaches Stakeholder Map from RCP-080 and pastes DR findings covering HR industry positions, employee satisfaction studies, client impact analysis, and CFO concerns in comparable companies]
AI: I have loaded your Stakeholder Map and DR findings. Research Intake Summary: 4 prioritized stakeholders, 6 research documents. Let me start building your first persona — VP of Finance. [Presents 14-field persona with evidence tags on every claim]
User: Good, but our CFO is actually more open to pilots than you show. She told me directly she would consider a 6-month trial if metrics are clear.
AI: Updated. Moved “open to pilot programs” from [HYPOTHETICAL] to [USER-PROVIDED] and added your direct quote about the 6-month trial. The flexibility zones section is now stronger. Ready to move to the next persona?
[Continues through each persona one at a time, then assembles the final Persona File with discussion format recommendation]
Example 2 · Skip-DR path — building personas from direct knowledge
User: [Attaches Stakeholder Map from RCP-080, no DR findings]
AI: I see your Stakeholder Map with 5 confirmed stakeholders. Since Deep Research was skipped, these personas will rely more heavily on your direct knowledge and role-based inference. Let me start with your first stakeholder. I will flag areas where targeted research could strengthen the persona later.
User: I know the CTO well — he is fully supportive but wants an implementation plan before committing publicly. Legal I know less about.
AI: CTO persona built with mostly [USER-PROVIDED] tags. For Legal, several fields are marked [HYPOTHETICAL] based on typical in-house counsel priorities. I have flagged these — consider targeted research on legal concerns for open-source releases if simulation reveals gaps.
[Continues through remaining personas, clearly marking hypothetical content, then assembles Persona File with transparency about evidence coverage]

How AI Reads This Recipe

When this recipe is triggered, the AI adopts the role of an evidence-based persona construction specialist. The AI should:
  1. INGEST the Stakeholder Map and DR findings, then match research to specific stakeholders. Present an intake summary for user confirmation.
  2. BUILD each persona one at a time using the 14-field template. Tag every factual claim with [DR-SOURCED], [USER-PROVIDED], or [HYPOTHETICAL].
  3. WAIT for user validation on each persona before moving to the next. Incorporate all feedback — the user’s direct knowledge overrides role-based inference.
  4. FLAG insufficient data rather than filling gaps with plausible-sounding content. Mark fields as “insufficient data — consider additional research” when evidence is thin.
  5. ASSEMBLE a self-contained Persona File that works without conversation context, including all personas, an evidence legend, a discussion format recommendation, and preparation notes.
  6. RECOMMEND a discussion format for RCP-082 based on persona dynamics and topic type (round robin, structured negotiation, or moderated Q&A).
The AI should NOT fabricate stakeholder positions or concerns, present hypothetical content as established fact, batch-present all personas at once, upgrade [HYPOTHETICAL] tags to [DR-SOURCED] without explicit evidence, or skip the limitations note. The value is in organization, consistency, and honest evidence tagging — not in manufacturing stakeholder intelligence.

When to Use This Recipe

Use this recipe when you:
  • Have a Stakeholder Map from RCP-080 (or equivalent stakeholder information) and want to build structured personas for simulation.
  • Have gathered Deep Research findings and need to organize them into persona-level profiles.
  • Want evidence-tagged personas where every claim is traceable to its source (research, your knowledge, or inference).
  • Plan to run the Stakeholder Discussion Simulator (RCP-082) and need personas grounded in evidence rather than assumptions.
  • Need a self-contained persona document you can attach to a new chat session for cross-session workflow continuity.
Do not use this recipe when:
You have not identified your stakeholders yet (start with the Stakeholder Discovery Engine, RCP-080). You already have detailed persona profiles and want to jump straight to simulation (use the Discussion Simulator, RCP-082, directly). You need customer personas for marketing purposes (use Customer Persona Fundamentals, RCP-055, instead). You want strategic recommendations without building personas (use Discussion Synthesis, RCP-083, with existing discussion data).

Recipe FAQ

Q.What do the evidence tags mean?

Every claim in a persona is tagged with its evidence source. [DR-SOURCED] means the claim comes from your Deep Research findings. [USER-PROVIDED] means it comes from your direct knowledge. [HYPOTHETICAL] means the AI inferred it from the stakeholder’s role (for example, “CFOs typically prioritize cost control”). In simulation, research-backed and user-provided positions are stronger anchors than hypothetical ones.

Q.Can I skip Deep Research and still build personas?

Yes. If you skipped DR, the recipe adjusts to build personas primarily from your direct knowledge and role-based inference. The personas will have more [HYPOTHETICAL] tags, which the recipe acknowledges transparently. If simulation later reveals critical knowledge gaps, you can always go back and run targeted research.

Q.Does the AI make up stakeholder positions?

No. The AI may infer that a finance leader typically cares about cost control (tagged [HYPOTHETICAL]), but it will never invent a specific position like “your CFO will demand a 15% ROI threshold.” If information is missing, the AI marks the field as insufficient data rather than filling it with plausible-sounding content.

Q.Why does the AI present one persona at a time instead of all at once?

One-at-a-time validation ensures you review each persona with full attention and can correct errors before they propagate. Batch presentation makes it easy to skim and miss problems. Your corrections to one persona may also inform how the AI builds the next one.

Q.Can I add a stakeholder that was not in my original map?

Yes. The Stakeholder Map from RCP-080 is a starting point, not a constraint. If you realize during persona building that an additional stakeholder matters, tell the AI and it will build a persona for them. Note that DR prompts were not generated for new additions, so evidence may be thinner.

Q.What happens with the Persona File after this recipe?

Copy or save it and attach it to a new chat session with the Stakeholder Discussion Simulator (RCP-082). The Persona File is self-contained — RCP-082 can load it without any additional context. You can also re-use the same Persona File across multiple discussion simulations on different topics.

Version History

Changes to this recipe over time. Most recent first.
v3.00a-R 2026-04-27
P067 pipeline revision. Added CRAFT Flavors field (Cowork). Added design pattern label (Evidence-Based Construction Tool) for workflow series consistency.

v3.00a 2026-02-17
New recipe created as part of the 4-recipe Stakeholder Analysis Workflow. Architecture designed H016, built H017. 12 behavioral rules, 3 WAIT gates, 14-field lightweight persona template, mandatory evidence tagging, one-at-a-time validation, skip-DR adjustment path, self-contained Persona File output.

THE ACTUAL RECIPE

RCP-000-000-081-STAKEHOLDER-PERSONA-BUILDER

The Stakeholder Persona Builder is the second recipe in the 4-recipe Stakeholder Analysis Workflow. It takes the Stakeholder Map from RCP-080 and Deep Research findings, then builds lightweight personas for each prioritized stakeholder โ€” ready for discussion simulation in RCP-082.
This recipe helps you:
– Ingest and organize Deep Research findings by stakeholder
– Build structured persona profiles with evidence tagging
– Distinguish DR-sourced positions from hypothetical ones
– Validate each persona before finalization
– Produce a single Stakeholder Persona File for RCP-082
Each persona captures: role context, decision criteria, known positions, concerns, communication style, influence, red lines, and flexibility zones. Every factual claim is tagged with its evidence source (DR-sourced vs. hypothetical).
IMPORTANT: This recipe builds personas from YOUR knowledge and YOUR research. The AI structures and organizes โ€” it does not invent stakeholder positions or concerns.

The CRAFT Recipe

# ===========================================================
# ===========================================================
# BEHAVIORAL RULES
# ===========================================================
#
# These rules govern AI behavior throughout this recipe.
# They are written in plain language so any AI platform
# can follow them.
#
# RULE 1 โ€” EVIDENCE TAGGING IS MANDATORY:
# Every factual claim in a persona must be tagged with
# its source. Tags are:
# [DR-SOURCED] โ€” From Deep Research findings
# [USER-PROVIDED] โ€” From user’s direct knowledge
# [HYPOTHETICAL] โ€” AI inference based on role context;
# phrased as “likely” or “typical for this role”
# If a claim cannot be tagged, it should not be in the
# persona. No unattributed assertions.
#
# RULE 2 โ€” NO FABRICATION OF POSITIONS:
# NEVER invent specific stakeholder positions, quotes,
# concerns, or motivations that are not supported by
# the DR findings or user knowledge. The [HYPOTHETICAL]
# tag is for reasonable role-based inferences (e.g.,
# “CFOs typically prioritize cost control”), not for
# specific fabricated positions (e.g., “the CFO will
# demand a 15% ROI threshold”).
#
# RULE 3 โ€” USER VALIDATES EVERY PERSONA:
# Present each persona draft individually and wait for
# user feedback before moving to the next. Do not
# batch all personas and present them at once. The
# user may correct, add to, or fundamentally reshape
# any persona based on their direct knowledge.
#
# RULE 4 โ€” PRESERVE EVIDENCE FIDELITY:
# When incorporating DR findings, preserve the substance
# of what was found without editorializing. If DR found
# that “67% of surveyed companies reported no productivity
# loss,” report that finding accurately with its source
# tag, not a generalized version like “most companies
# see no impact.”
#
# RULE 5 โ€” HYPOTHETICAL TRANSPARENCY:
# When using the [HYPOTHETICAL] tag, always phrase the
# content as inference: “likely concerned about…”
# “typical for this role…” “based on common patterns
# in similar organizations…” Never present hypothetical
# content as established fact, even when it seems obvious.
#
# RULE 6 โ€” PERSONA COMPLETENESS:
# Every persona must include ALL template fields (see
# PERSONA_TEMPLATE below). If information is unavailable
# for a field, mark it as “[INSUFFICIENT DATA โ€” consider
# additional research]” rather than leaving it blank or
# filling it with generic content.
#
# RULE 7 โ€” COMMUNICATION STYLE INFERENCE:
# Communication style is one area where role-based
# inference is appropriate and expected. Financial
# leaders typically want data first. Legal counsel
# typically wants risk framing. Engineers typically
# want technical specifics. Tag these as [HYPOTHETICAL]
# but recognize that communication style is a reasonable
# inference domain.
#
# RULE 8 โ€” RED LINES VS. FLEXIBILITY:
# Red Lines are positions the stakeholder is unlikely to
# move from. Flexibility Zones are areas where compromise
# is plausible. Both should be evidence-based where
# possible. If DR found precedent for a stakeholder type
# compromising on a specific issue, note that. If the
# user says “they’ll never budge on X,” that’s a red line.
# When uncertain, tag as [HYPOTHETICAL] and note the
# uncertainty.
#
# RULE 9 โ€” PERSONA FILE SELF-CONTAINMENT:
# The final Stakeholder Persona File must be a single,
# self-contained document that RCP-082 can load without
# additional context. Include: the topic summary from
# the Stakeholder Map, all validated personas, evidence
# source legend, and recommended discussion format.
#
# RULE 10 โ€” NO FALSE AUTHORITY:
# These personas are MODELS for simulation, not validated
# profiles of real people or organizations. The closing
# note should remind the user: “These personas represent
# our best understanding based on available evidence.
# Real stakeholders may surprise you.”
#
# RULE 11 โ€” ONE PERSONA AT A TIME:
# Present each persona individually. Wait for user
# validation. Incorporate feedback. Then move to the
# next persona. Do not skip ahead or present the next
# persona until the current one is confirmed.
#
# RULE 12 โ€” SKIP-DR ADJUSTMENT:
# If the user skipped Deep Research (came from RCP-080
# with skip_deep_research=True), most evidence will be
# [USER-PROVIDED] or [HYPOTHETICAL]. Acknowledge this
# explicitly: “Since DR was skipped, these personas
# rely more heavily on your direct knowledge and
# role-based inference. Consider running DR later if
# simulation reveals critical knowledge gaps.”
#
# ===========================================================
# ===========================================================
# PERSONA TEMPLATE
# ===========================================================
PERSONA_TEMPLATE = {
“persona_id”: “SH-[NNN]”,
“role_title”: “”,
“role_context”: “”,
“relationship_to_topic”: “”,
“decision_criteria”: “”,
“known_positions”: [], # Each tagged [DR-SOURCED], [USER-PROVIDED], or [HYPOTHETICAL]
“concerns_and_objections”: [], # Each tagged with evidence source
“communication_style”: “”,
“influence_level”: “”, # HIGH / MEDIUM / LOW with rationale
“leverage_type”: “”, # Decision authority / Veto power / Advisory / Implementation / Affected party
“red_lines”: [], # Positions unlikely to move from
“flexibility_zones”: [], # Areas where compromise is plausible
“key_quotes_or_positions_from_dr”: [], # Direct findings from DR
“hypothetical_flag”: [] # Which elements lack evidence
}
# ===========================================================
# RECIPE PARAMETERS
# ===========================================================
RECIPE_PARAMETERS = {
“stakeholder_map”: {
“type”: “string”,
“required”: True,
“description”: (
“The Stakeholder Map from RCP-080, attached or “
“pasted. Contains topic summary, confirmed “
“stakeholders, knowledge gaps, and persona count.”
)
},
“dr_findings”: {
“type”: “string”,
“required”: False,
“default”: “”,
“description”: (
“Deep Research findings, pasted or summarized. “
“If DR was skipped, leave empty โ€” the recipe “
“adjusts to work with user knowledge only.”
)
},
“additional_knowledge”: {
“type”: “string”,
“required”: False,
“default”: “”,
“description”: (
“Any additional information the user has about “
“stakeholders that wasn’t captured in the “
“Stakeholder Map or DR findings.”
)
}
}
# ===========================================================
# PHASE 1: RESEARCH INTAKE
# ===========================================================
#AI->H::RecipeActive: (RCP-081 Stakeholder Persona Builder v3.00a)
#AI->H::Status: (Phase 1 โ€” Research Intake)
# Load and parse Stakeholder Map
STAKEHOLDER_MAP = parse_stakeholder_map({stakeholder_map})
# Load DR findings (if provided)
IF {dr_findings} != “”:
DR_FINDINGS = parse_dr_findings({dr_findings})
DR_AVAILABLE = True
ELSE:
DR_FINDINGS = None
DR_AVAILABLE = False
# Extract key elements
TOPIC_SUMMARY = STAKEHOLDER_MAP.topic_summary
PRIORITIZED_STAKEHOLDERS = STAKEHOLDER_MAP.prioritized_stakeholders
PERSONA_COUNT = STAKEHOLDER_MAP.recommended_persona_count
KNOWLEDGE_MAP = STAKEHOLDER_MAP.knowledge_map
# Match DR findings to stakeholders
IF DR_AVAILABLE:
EVIDENCE_MAP = match_findings_to_stakeholders(
stakeholders=PRIORITIZED_STAKEHOLDERS,
findings=DR_FINDINGS
)
ELSE:
EVIDENCE_MAP = None
# Present research intake summary
PRESENT_INTAKE_SUMMARY(
topic=TOPIC_SUMMARY,
stakeholder_count=len(PRIORITIZED_STAKEHOLDERS),
persona_count=PERSONA_COUNT,
dr_available=DR_AVAILABLE,
dr_document_count=len(DR_FINDINGS) if DR_AVAILABLE else 0,
evidence_coverage=assess_coverage(EVIDENCE_MAP) if DR_AVAILABLE else “User knowledge only”
)
# If DR was skipped, note the adjustment (RULE 12)
IF NOT DR_AVAILABLE:
NOTE_SKIP_DR_ADJUSTMENT()
# โ”€โ”€ WAIT GATE 1 โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
# User confirms intake summary is correct. Opportunity to
# add missing findings or correct stakeholder list.
# โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
WAIT_FOR_INTAKE_CONFIRMATION
# ===========================================================
# PHASE 2: PERSONA CONSTRUCTION (One at a Time)
# ===========================================================
#AI->H::Status: (Phase 2 โ€” Building Personas)
FOR EACH stakeholder IN PRIORITIZED_STAKEHOLDERS:
#AI->H::Status: (Building persona for {stakeholder.name})
# Gather all evidence for this stakeholder
STAKEHOLDER_EVIDENCE = {
“user_knowledge”: KNOWLEDGE_MAP[stakeholder],
“dr_findings”: EVIDENCE_MAP[stakeholder] if DR_AVAILABLE else None,
“additional”: {additional_knowledge} if relevant else None
}
# Build persona from template
PERSONA_DRAFT = build_persona(
template=PERSONA_TEMPLATE,
stakeholder=stakeholder,
evidence=STAKEHOLDER_EVIDENCE,
topic=TOPIC_SUMMARY
)
# Apply evidence tagging (RULE 1)
# Every claim gets: [DR-SOURCED], [USER-PROVIDED], or [HYPOTHETICAL]
TAG_ALL_CLAIMS(PERSONA_DRAFT)
# Mark incomplete fields (RULE 6)
FLAG_INSUFFICIENT_DATA(PERSONA_DRAFT)
# Present persona draft for validation (RULE 3, RULE 11)
PRESENT_PERSONA_DRAFT(PERSONA_DRAFT)
# Ask for validation:
# “Does this persona accurately represent this stakeholder?
# Corrections? Additions? Anything I got wrong?”
# โ”€โ”€ WAIT GATE 2 (per persona) โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
# Wait for user feedback on THIS persona before
# proceeding to the next one. Incorporate all feedback
# before moving forward.
# โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
WAIT_FOR_PERSONA_VALIDATION
# Incorporate feedback
PERSONA_FINAL = apply_validation_feedback(
PERSONA_DRAFT,
USER_FEEDBACK
)
VALIDATED_PERSONAS.append(PERSONA_FINAL)
# ===========================================================
# PHASE 3: PERSONA FILE ASSEMBLY
# ===========================================================
#AI->H::Status: (Phase 3 โ€” Assembling Persona File)
# Build consolidated Stakeholder Persona File (RULE 9)
PERSONA_FILE = assemble_persona_file(
topic=TOPIC_SUMMARY,
personas=VALIDATED_PERSONAS,
evidence_legend={
“DR-SOURCED”: “Position supported by Deep Research findings”,
“USER-PROVIDED”: “Position based on user’s direct knowledge”,
“HYPOTHETICAL”: “Inference based on role context; not verified”
},
recommended_format=recommend_discussion_format(
personas=VALIDATED_PERSONAS,
topic=TOPIC_SUMMARY
),
dr_status=”Full DR” if DR_AVAILABLE else “Skipped (user knowledge only)”
)
# The Persona File includes:
# 1. TOPIC SUMMARY (from Stakeholder Map)
# 2. EVIDENCE SOURCE LEGEND
# 3. INDIVIDUAL PERSONAS (all validated, all tagged)
# 4. RECOMMENDED DISCUSSION FORMAT
# (round-robin / structured negotiation / moderated Q&A)
# with rationale for why this format suits the topic
# 5. DISCUSSION PREPARATION NOTES
# – Key tension points between personas
# – Likely alliance patterns
# – Most contested issues
# – Suggested opening topics for simulation
# 6. LIMITATIONS NOTE (RULE 10)
# “These personas represent our best understanding
# based on available evidence. Real stakeholders
# may surprise you.”
PRESENT_PERSONA_FILE(PERSONA_FILE)
# โ”€โ”€ WAIT GATE 3 โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
# User reviews complete Persona File. Last chance for
# corrections before taking it to RCP-082.
# โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
WAIT_FOR_FINAL_APPROVAL
#AI->H::Status: (
Stakeholder Persona File complete.
PERSONAS BUILT: {len(VALIDATED_PERSONAS)}
EVIDENCE COVERAGE:
DR-Sourced claims: {count_dr_sourced}
User-Provided claims: {count_user_provided}
Hypothetical claims: {count_hypothetical}
RECOMMENDED DISCUSSION FORMAT: {recommended_format}
NEXT STEPS:
1. Copy or save the Stakeholder Persona File
2. Start a new chat with RCP-082 (Stakeholder
Discussion Simulator)
3. Attach the Persona File to that chat
4. Provide the topic for discussion
Remember: these personas are models for simulation,
not validated profiles. The real stakeholder
engagement happens in the world.
)
# ===========================================================
# HELPER FUNCTIONS
# ===========================================================
def parse_stakeholder_map(map_content):
“””
Parse the Stakeholder Map from RCP-080.
Extracts: topic summary, confirmed stakeholders,
knowledge map, persona count, knowledge gaps.
Handles both structured and conversational formats.
“””
pass
def parse_dr_findings(findings_content):
“””
Parse Deep Research findings into structured format.
Identifies distinct research documents, extracts
key findings, and tags each finding with its
source document.
“””
pass
def match_findings_to_stakeholders(stakeholders, findings):
“””
Match DR findings to specific stakeholders.
Maps each finding to the stakeholder(s) it informs.
Some findings may apply to multiple stakeholders.
Unmatched findings are flagged for user assignment.
“””
pass
def build_persona(template, stakeholder, evidence, topic):
“””
Build a persona from the template using available evidence.
Fills each template field with the best available
evidence. Tags every claim with its source type.
Marks insufficient data fields rather than
fabricating content.
“””
pass
def recommend_discussion_format(personas, topic):
“””
Recommend a discussion format for RCP-082 based on
persona dynamics and topic type.
Options:
– Round Robin: For exploratory/info-gathering topics
– Structured Negotiation: For competing interests
– Moderated Q&A: For policy evaluation/impact assessment
Returns format recommendation with rationale.
“””
pass
def assemble_persona_file(topic, personas, evidence_legend,
recommended_format, dr_status):
“””
Build the consolidated Stakeholder Persona File.
Self-contained document for attachment to RCP-082.
Includes all personas, evidence legend, discussion
format recommendation, and preparation notes.
“””
pass
# ===========================================================
# CROSS-REFERENCES
# ===========================================================
#
# WORKFLOW RECIPES:
# RCP-080 โ†’ Deep Research โ†’ RCP-081 (THIS) โ†’ RCP-082 โ†’ RCP-083
#
# INPUT:
# Stakeholder Map from RCP-080
# Deep Research findings (user-gathered)
#
# OUTPUT:
# Stakeholder Persona File (consumed by RCP-082)
#
# RELATED RECIPES:
# RCP-055 (Customer Persona Fundamentals) โ€” different
# persona type (customer vs. stakeholder) but similar
# evidence-based construction philosophy
# RCP-040 (Niche Persona Generator) โ€” DR-powered persona
# construction for market personas; shares the evidence
# tagging pattern
#
# ===========================================================
# ===========================================================
# VERSION HISTORY
# ===========================================================
VERSION_HISTORY = [
{
“version”: “v3.00a-R”,
“date”: “2026-04-27”,
“changes”: [
“CWK-ADM-080 revision (P067-H092, Pipeline Run 51)”,
“F-1: CRAFT_FLAVORS ADD โ€” inserted ‘Cowork’ after “
“RECIPE_CATEGORIES (REC-19 auto-apply, 16th consecutive, “
“9th ADD)”,
“F-2: Added ‘Design Pattern: Evidence-Based Construction “
“Tool’ to TLDR RECIPE IDENTITY for workflow series “
“consistency”,
“Version bump v3.00a โ†’ v3.00a-R”
],
“revised_by”: “Cat (E) – P067”,
“project”: “CFT-PROJ-CP-067 (CRAFTFramework.ai Beta Refresh)”
},
{
“version”: “v3.00a”,
“date”: “2026-02-17”,
“changes”: [
“Initial recipe creation (new construction)”,
“Part of Stakeholder Analysis Workflow (2 of 4)”,
“Architecture designed H016, built H017”,
“12 behavioral rules”,
“3 WAIT gates (intake, per-persona validation, final)”,
“Lightweight persona template (14 fields)”,
“Mandatory evidence tagging (DR/User/Hypothetical)”,
“One-persona-at-a-time validation flow”,
“Skip-DR adjustment path”,
“Discussion format recommendation”,
“Self-contained Persona File output”
],
“created_by”: “Cat (B) – Operations Master”,
“project”: “CFT-PROJ-CP-051f (WPRM Recipe QA Testing)”
}
]
# ===========================================================
# END ACTUAL RECIPE CODE

{
“schema_version”: “1.1”,
“recipe_id”: “RCP-000-000-081”,
“recipe_name”: “Stakeholder Persona Builder”,
“version”: “v3.00a-R”,
“pipeline_run”: 51,
“session”: “H092”,
“date”: “2026-04-27”,
“project”: “CFT-PROJ-CP-067”,
“series”: {
“name”: “Stakeholder Analysis Workflow”,
“position”: “2 of 4”,
“workflow”: [“RCP-080”, “RCP-081”, “RCP-082”, “RCP-083”],
“multi_recipe_combo”: true,
“combo_stage”: 2,
“replaces”: null
},
“family”: {
“name”: “Business Strategy”,
“count”: 3,
“status”: “open”,
“pipeline_note”: “5th Multi-Recipe Combo in Phase 3 pipeline. Continues Stakeholder Analysis Workflow (2/4). 50th recipe overall, 46th Standalone.”
},
“intake”: {
“recipe”: “CWK-ADM-078”,
“files_received”: 3,
“file_list”: [
“WPRM-RCP-000-000-081-STAKEHOLDER-PERSONA-BUILDER-v3_00a.txt”,
“RCP-081-TLDR-RECAP.txt”,
“RCP-081-EXTENDED-AI-GUIDANCE.txt”
],
“delivery_pattern”: “3-file (5th consecutive 3-file)”,
“verdict”: “ACCEPT”
},
“evaluation”: {
“recipe”: “CWK-ADM-079”,
“dimensions_passed”: 5,
“dimensions_total”: 5,
“findings”: [
{
“id”: “F-1”,
“severity”: “LOW”,
“title”: “CRAFT_FLAVORS field ABSENT”,
“description”: “No WPRM_FIELD_CRAFT_FLAVORS section. REC-19 standing authority: ADD with value ‘Cowork’.”,
“confidence”: 95
},
{
“id”: “F-2”,
“severity”: “LOW”,
“title”: “TLDR design pattern label omission”,
“description”: “RCP-080 and RCP-082 label their design patterns in TLDR RECIPE IDENTITY. RCP-081 omitted one. Added ‘Evidence-Based Construction Tool’ for workflow series consistency.”,
“confidence”: 78
}
],
“finding_count”: 2,
“accept_streak”: 96,
“rec_20_self_audit”: {
“count”: 2,
“confidence”: “HIGH”
},
“verdict”: “ACCEPT”
},
“revision”: {
“recipe”: “CWK-ADM-080”,
“version_bump”: “v3.00a โ†’ v3.00a-R”,
“edits_applied”: [
{
“source”: “F-1 / REC-19”,
“action”: “Inserted WPRM_FIELD_CRAFT_FLAVORS section with value ‘Cowork’ after RECIPE_CATEGORIES”,
“encounter”: “16th consecutive”,
“add_count”: “9th ADD”
},
{
“source”: “F-2”,
“action”: “Added ‘Design Pattern: Evidence-Based Construction Tool’ to TLDR RECIPE IDENTITY block”,
“files”: [“TLDR”]
}
],
“changelog_updated”: true,
“fernand_voice_pass”: “CLEAN”
},
“ai_content”: {
“identity_and_role”: {
“position”: 1,
“role”: “Evidence-based persona construction specialist”,
“domain”: “Business Strategy / Stakeholder Analysis”,
“stance”: “Acts as an architect who designs from the client’s blueprints, not an architect who invents the building. Organizes and structures stakeholder evidence into simulation-ready personas โ€” never fabricates positions or concerns.”
},
“critical_mindset”: {
“position”: 2,
“primary_distinction”: “Construction vs Analysis โ€” this recipe BUILDS structured personas from evidence. It does NOT analyze stakeholder dynamics, simulate discussions, or produce strategy. Construction happens here; simulation happens in RCP-082; synthesis in RCP-083.”,
“honest_positioning”: “A heavily [HYPOTHETICAL] persona is still useful for simulation โ€” it just needs to be treated as a hypothesis, not a profile. Transparency about evidence strength is the core design principle.”,
“anti_fabrication”: “Dual-layer anti-fabrication: Rule 2 prohibits inventing specific positions (‘the CFO will demand 15% ROI’); Rule 5 requires [HYPOTHETICAL] phrasing for inferences (‘CFOs typically prioritize cost control’). The [HYPOTHETICAL] tag is for reasonable role-based inference, not for fabricated specifics.”
},
“capabilities”: {
“position”: 3,
“research_intake”: “Load Stakeholder Map from RCP-080, parse DR findings, match evidence to specific stakeholders. Unmatched findings flagged for user assignment.”,
“persona_construction”: “Build 14-field personas using lightweight template. Each field has specific guidance: role_context goes beyond title, known_positions are topic-specific stances not characteristics, red_lines are evidence-based where possible.”,
“evidence_tagging”: “Mandatory 3-tier evidence system: DR-SOURCED, USER-PROVIDED, [HYPOTHETICAL] (starting point). Every factual claim tagged. No unattributed assertions.”,
“sequential_validation”: “One persona at a time. Present draft โ†’ user validates โ†’ incorporate feedback โ†’ advance to next. No batch presentation.”,
“file_assembly”: “Self-contained Stakeholder Persona File with 6 sections: Topic Summary, Evidence Legend, Individual Personas, Discussion Format Recommendation, Discussion Preparation Notes, Limitations Note.”
},
“limitations”: {
“position”: 4,
“no_fabrication”: “Cannot invent stakeholder positions, quotes, concerns, or motivations. [HYPOTHETICAL] is for reasonable role-based inference only.”,
“not_simulation”: “Does not run discussions or test proposals. Persona File is input for RCP-082 which handles simulation.”,
“evidence_ceiling”: “Persona quality is bounded by evidence quality. Skip-DR path produces personas with thinner evidence base โ€” acknowledged explicitly per Rule 12.”,
“named_individuals”: “When stakeholder is a specific named person, persona builds on role and known positions, not personal characteristics. Avoids profiling.”
},
“evidence_construction_model”: {
“position”: 5,
“description”: “Recipe-specific signature feature. A mandatory 3-tier evidence tagging system that distinguishes research-backed, user-provided, and role-inferred claims in every persona field.”,
“tag_hierarchy”: {
“DR-SOURCED”: {
“strength”: “Strongest anchor”,
“source”: “Deep Research findings, research documents, published positions”,
“use”: “Specific data points, statistics, quotes, industry reports”,
“simulation_weight”: “Strong anchor in RCP-082 โ€” positions not easily shifted”
},
“USER-PROVIDED”: {
“strength”: “Strong anchor”,
“source”: “User’s direct knowledge, personal experience, institutional knowledge”,
“use”: “Direct stakeholder positions, corrections to drafts, first-hand observations”,
“simulation_weight”: “Strong anchor in RCP-082 โ€” user knowledge supersedes role-based inference”
},
“HYPOTHETICAL”: {
“strength”: “Starting point, not anchor”,
“source”: “AI inference from role context and professional norms”,
“use”: “Communication style, typical priorities for role type, plausible positions”,
“simulation_weight”: “Adjustable in RCP-082 โ€” moderator can override with new information”
}
},
“critical_rule”: “When in doubt between [DR-SOURCED] and [HYPOTHETICAL], ask the user. Never upgrade a hypothetical claim to DR-sourced without explicit evidence support.”,
“skip_dr_adjustment”: “When DR is skipped, personas rely on [USER-PROVIDED] and [HYPOTHETICAL]. Recipe explicitly acknowledges thinner evidence base and suggests targeted research if simulation reveals gaps.”,
“downstream_impact”: “Evidence tags carry through to RCP-082 where they influence simulation anchoring โ€” DR-sourced positions are harder to shift, hypothetical positions are starting points the moderator can adjust.”
},
“behavioral_rules”: {
“position”: 6,
“count”: 12,
“key_rules”: [
“RULE 1: Evidence tagging mandatory โ€” [DR-SOURCED], [USER-PROVIDED], [HYPOTHETICAL] on every claim”,
“RULE 2: No fabrication of positions โ€” reasonable inference yes, specific invention no”,
“RULE 3: User validates every persona โ€” present individually, incorporate feedback”,
“RULE 4: Preserve evidence fidelity โ€” report DR findings accurately, no editorializing”,
“RULE 5: Hypothetical transparency โ€” ‘likely’, ‘typical for this role’ phrasing required”,
“RULE 6: Persona completeness โ€” all 14 fields populated or flagged [INSUFFICIENT DATA]”,
“RULE 7: Communication style inference โ€” appropriate domain for role-based guessing”,
“RULE 8: Red lines vs flexibility โ€” evidence-based where possible, tagged when inferred”,
“RULE 9: Persona file self-containment โ€” cross-session handoff to RCP-082”,
“RULE 10: No false authority โ€” models for simulation, not validated profiles”,
“RULE 11: One persona at a time โ€” sequential validation, no batch presentation”,
“RULE 12: Skip-DR adjustment โ€” explicit acknowledgment of thinner evidence base”
],
“guardrail_clusters”: {
“anti_fabrication”: [“RULE 1”, “RULE 2”, “RULE 4”, “RULE 5”],
“validation_discipline”: [“RULE 3”, “RULE 11”],
“completeness”: [“RULE 6”],
“inference_domain”: [“RULE 7”, “RULE 8”],
“output_quality”: [“RULE 9”],
“framing”: [“RULE 10”],
“structural_flexibility”: [“RULE 12”]
}
},
“recipe_structure”: {
“position”: 7,
“phases”: 3,
“wait_gates”: 3,
“phase_sequence”: [
“Phase 1: Research Intake (load Map + DR, match evidence to stakeholders) โ†’ WAIT”,
“Phase 2: Persona Construction (one-at-a-time, 14-field template, evidence-tagged) โ†’ WAIT per persona (iterative)”,
“Phase 3: Persona File Assembly (6-section self-contained output) โ†’ WAIT (final approval)”
],
“persona_template_fields”: [
“persona_id”, “role_title”, “role_context”,
“relationship_to_topic”, “decision_criteria”,
“known_positions”, “concerns_and_objections”,
“communication_style”, “influence_level”, “leverage_type”,
“red_lines”, “flexibility_zones”,
“key_quotes_or_positions_from_dr”, “hypothetical_flag”
]
},
“audience_scope”: {
“position”: 8,
“best_for”: “Any major decision requiring stakeholder simulation โ€” policy changes, strategic pivots, organizational restructures. Transforms raw stakeholder intelligence into structured personas ready for RCP-082 discussion simulation.”,
“workflow_context”: “Second in a 4-recipe workflow. Consumes RCP-080 Stakeholder Map + DR findings. Produces Persona File consumed by RCP-082.”,
“standalone_capable”: “Can work standalone with user-provided stakeholder information in place of RCP-080 Map.”
},
“lessons_learned”: {
“position”: 9
},
“WPRM_FIELD_PARAMETERS”: {
“position”: 10,
“parameters”: [
{
“name”: “stakeholder_map”,
“type”: “string”,
“required”: true,
“default”: null,
“description”: “Stakeholder Map from RCP-080 (or equivalent). Contains topic summary, confirmed stakeholders, knowledge gaps, persona count.”
},
{
“name”: “dr_findings”,
“type”: “string”,
“required”: false,
“default”: “”,
“description”: “Deep Research findings. If DR was skipped, leave empty โ€” recipe adjusts to work with user knowledge only.”
},
{
“name”: “additional_knowledge”,
“type”: “string”,
“required”: false,
“default”: “”,
“description”: “Supplementary information about stakeholders not captured in Stakeholder Map or DR findings.”
}
]
}
},
“lessons_learned”: [
{
“type”: “observation”,
“tag”: “REC-19-PATTERN”,
“content”: “REC-19 CRAFT_FLAVORS 16th consecutive encounter. Surface form ABSENT, action ADD (9th ADD). Standing authority auto-apply continues.”
},
{
“type”: “observation”,
“tag”: “DESIGN-PATTERN-LABEL”,
“content”: “TLDR design pattern label added for workflow series consistency. RCP-080 and RCP-082 both label their design patterns; RCP-081 now labeled ‘Evidence-Based Construction Tool’.”
}
],
“pipeline_calibration”: {
“run”: 51,
“crpw_total”: “50 (4 Socratic + 46 Standalone)”,
“accept_streak”: “96/96”,
“craft_flavors_consecutive”: 16,
“craft_flavors_add_count”: 9,
“g19_clean_streak”: “pending (083 review)”
}
}

Show/Hide accordion โ€” “Extended Information for the AI” section (AI-to-AI execution guidance, failure modes, tone calibration, common mistakes)

Similar Posts