
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
TL;DR
How To Start
STEP 1Provide Your Inputs
-
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.
STEP 2Confirm Research Intake
STEP 3Validate Each Persona
STEP 4Receive Your Persona File
Usage Examples
How AI Reads This Recipe
- INGEST the Stakeholder Map and DR findings, then match research to specific stakeholders. Present an intake summary for user confirmation.
- BUILD each persona one at a time using the 14-field template. Tag every factual claim with [DR-SOURCED], [USER-PROVIDED], or [HYPOTHETICAL].
- WAIT for user validation on each persona before moving to the next. Incorporate all feedback — the user’s direct knowledge overrides role-based inference.
- FLAG insufficient data rather than filling gaps with plausible-sounding content. Mark fields as “insufficient data — consider additional research” when evidence is thin.
- ASSEMBLE a self-contained Persona File that works without conversation context, including all personas, an evidence legend, a discussion format recommendation, and preparation notes.
- RECOMMEND a discussion format for RCP-082 based on persona dynamics and topic type (round robin, structured negotiation, or moderated Q&A).
When to Use This Recipe
- 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.
Recipe FAQ
Q.What do the evidence tags mean?
Q.Can I skip Deep Research and still build personas?
Q.Does the AI make up stakeholder positions?
Q.Why does the AI present one persona at a time instead of all at once?
Q.Can I add a stakeholder that was not in my original map?
Q.What happens with the Persona File after this recipe?
Version History
THE ACTUAL RECIPE
RCP-000-000-081-STAKEHOLDER-PERSONA-BUILDER
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)
