Skip to content

Persona Evolution Workshop

New in v1.3.3. A hands-on workshop that walks you through identifying, scoring, evolving, and promoting FCC personas. By the end you will have authored a custom persona targeting a specific archetype family and evolution stage.

Prerequisites

Before starting, ensure you have:

Learning objectives

By the end of this workshop you will be able to:

  1. Classify an arbitrary persona into one of the 6 archetype families from its YAML alone.
  2. Score a persona on the 6-trait Discernment Matrix.
  3. Evolve a persona from STRUCTURED to SEMANTIC by adding cross-references and discernment scores.
  4. Promote a base persona to a champion by wiring champion_of and orchestrates fields.
  5. Design a cross-family collaboration scenario.
  6. Author a fresh persona from scratch in a chosen family + stage.

Workshop roadmap

flowchart LR
    E1[Ex1: Classify] --> E2[Ex2: Score]
    E2 --> E3[Ex3: Evolve]
    E3 --> E4[Ex4: Promote]
    E4 --> E5[Ex5: Scenario]
    E5 --> E6[Ex6: Author]

Exercise 1 — Identify the archetype family

Problem. Given the following persona YAML snippet, identify the archetype family.

Starter YAML.

- id: TTS
  name: Test Triage Specialist
  role_title: Test Triage Specialist
  category: devops
  riscear:
    role: Analyse failing tests, classify failures by root cause, and route them.
    inputs: [CI failure logs, flake reports, recent code changes]
    style: Methodical, sceptical, evidence-first.
    constraints:
      - Do not assume flake without 3 runs of evidence.
      - Chain-of-custody: every triage links back to the primary log.
    expected_output:
      - Failure classification report
      - Triage decision log with citations
      - Flake candidates list with evidence
    archetype: The Test Detective
    responsibilities:
      - Maintain triage taxonomy
      - Triangulate flake vs. regression
    role_skills: [CI log archaeology, pytest idioms, failure pattern libraries]
    role_collaborators: [DVE, PBD, QGD]

Expected outcome. This is an Investigator. Key signals:

  • style is "methodical, sceptical, evidence-first" — textbook investigator.
  • constraints include "chain-of-custody" — diagnostic of Investigators.
  • expected_output is a findings report with citations.
  • Dominant traits implied: Curiosity + Humility.

Tip. If the archetype name is ambiguous (it is — "The Test Detective" reads ambivalently), look at Constraints and Expected Output. These two fields discriminate the family better than any other.

Exercise 2 — Score the Discernment Matrix

Problem. Score TTS above on the 6 traits × 7 rating dimensions.

Starter scoring template.

discernment_matrix:
  humility: { self_awareness: ?, openness_to_feedback: ?, acknowledges_limits: ? }
  professional_background: { domain_depth: ?, credentials: ?, experience: ? }
  curiosity: { question_density: ?, exploration_rate: ?, follow_through: ? }
  taste: { aesthetic_judgement: ?, pattern_recognition: ?, selectivity: ? }
  inclusivity: { perspective_range: ?, accessibility_awareness: ? }
  responsibility: { ownership: ?, audit_trail: ?, escalation_discipline: ? }

Expected outcome. For an Investigator-family Test Triage Specialist, expect high scores on Curiosity and Humility, medium-high on Responsibility, medium on Professional Background, low-medium on Taste and Inclusivity.

Tip. Score relative to the family median, not absolutely. A score of 0.7 on Curiosity means "high even for an Investigator."

Exercise 3 — Evolve a base persona to the next stage

Problem. You are given a STRUCTURED-stage persona. Evolve it to SEMANTIC by adding 3 things: (a) cross-reference entries, (b) full discernment scores, (c) vocabulary-resolvable role_skills.

Starter YAML (STRUCTURED).

- id: CRS
  name: Change Request Steward
  role_title: Change Request Steward
  category: governance
  riscear:
    role: Review and approve change requests affecting regulated systems.
    style: Authoritative, policy-first, audit-ready.
    constraints:
      - Cannot approve without impact analysis.
      - Documentation is prerequisite, not afterthought.
    expected_output:
      - Approved/rejected change requests with rationale
      - Monthly change digest
    archetype: Change Shepherd
    role_collaborators: [DGS, GCA]

Expected outcome. The persona should gain:

  1. 3 additional collaborators (at least), e.g. [DGS, GCA, KVC, PTE, DPO] and an entry in src/fcc/data/personas/cross_reference.yaml.
  2. Full discernment scores with rationales.
  3. Role skills that resolve against entries in src/fcc/data/objectmodel/ — e.g. ["ITIL change management", "OPA policy bundles"] with mappings.

Tip. Run fcc validate --personas after editing; the validator lists unresolved cross-reference IDs.

Exercise 4 — Promote a base persona to champion

Problem. Promote CRS from Exercise 3 to a champion that orchestrates 3 base personas.

Expected YAML.

- id: CRCH
  name: Change Request Steward Champion
  category: champion
  champion_of: CRS
  orchestrates: [CRS, DGS, PTE]
  riscear:
    role: >-
      Orchestrate change-request reviews across governance, data governance,
      and privacy enforcement. Coordinate handoffs and ensure cross-artifact
      consistency.
    style: Orchestration-focused, synthesis-driven.
    archetype: The Change Director
    ...

Tips.

  • The champion inherits the archetype family of its base persona. A Shepherd's champion is still a Shepherd, with added orchestration responsibilities.
  • orchestrates should include the base persona (CRS) plus 2+ others.
  • Validate with fcc personas show-champions — the new champion should appear.

Exercise 5 — Design a cross-family collaboration scenario

Problem. Write a scenario JSON that exercises one persona from each family in a single FCC cycle.

Starter.

{
  "name": "workshop-cross-family-demo",
  "description": "Walk a request across all 6 archetype families.",
  "personas": [
    { "id": "RC",  "family": "Investigator" },
    { "id": "FAS", "family": "Quant" },
    { "id": "BC",  "family": "Architect" },
    { "id": "UG",  "family": "Storyteller" },
    { "id": "PTE", "family": "Safety Engineer" },
    { "id": "ACO", "family": "Shepherd" }
  ],
  "setup": { "ai_config": { "provider": "mock" } },
  "workflow": "fcc_complete_24_node"
}

Expected outcome. Running fcc simulate --scenario workshop-cross-family-demo should execute all 6 personas in dependency order. Mermaid of the intended flow:

flowchart LR
    RC[RC · Investigator] --> FAS[FAS · Quant]
    FAS --> BC[BC · Architect]
    BC --> UG[UG · Storyteller]
    BC --> PTE[PTE · Safety Engineer]
    PTE --> ACO[ACO · Shepherd]
    UG --> ACO

Tips.

  • The Shepherd usually runs last — it gates.
  • The Investigator usually runs first — it gathers.
  • Safety Engineer hardens before Shepherd approves.

Exercise 6 — Write a custom persona from scratch

Problem. Author a Storyteller-family persona at SEMANTIC stage that bridges ML lifecycle outputs to board-level audiences.

Expected shape (fill in the blanks).

- id: BRN
  name: Board Narrative Architect
  role_title: Board Narrative Architect
  category: stakeholder
  riscear:
    role: >-
      Translate ML lifecycle outputs (model cards, drift reports, bias
      audits) into board-level narratives. Produce exec briefs with
      progressive disclosure.
    inputs:
      - Model cards
      - Drift-report metrics
      - Bias-audit findings
      - Cross-ecosystem entity resolutions
    style: Audience-first, progressive-disclosure, narrative-coherent.
    constraints:
      - No uncited claims
      - Every exec brief must link back to primary artifacts
    expected_output:
      - Board one-pager
      - 10-slide deck
      - FAQ appendix
    archetype: The Board Translator
    responsibilities:
      - Audience research
      - Narrative synthesis
      - Editorial review
    role_skills:
      - Narrative craft
      - Progressive disclosure
      - Multi-audience targeting
    role_collaborators: [IRE, EC, MOS, IAN, ACO]

Tips.

  • Pick a category that matches an existing cluster (stakeholder is a natural home for board-facing storytellers).
  • Populate all 10 R.I.S.C.E.A.R. components.
  • Include at least 5 collaborators with mixed families (here: 2 Storytellers, 1 Other, 1 Quant, 1 Shepherd).
  • Run fcc validate --personas before committing.

Troubleshooting appendix

"My persona doesn't appear in fcc personas list"

Make sure the YAML file is under src/fcc/data/personas/ and is loaded by the PersonaRegistry.from_yaml_directory call. For custom personas outside the package, use PersonaRegistry.merge() to combine registries.

"Validation fails on unresolved role_collaborators"

Every collaborator ID must exist in the registry. Check for typos. If the collaborator is a new persona you are authoring, add it first.

"My champion doesn't show up in fcc personas show-champions"

Confirm category: champion, that champion_of names an existing base persona, and that orchestrates is a non-empty list.

"Evolution stage doesn't advance"

The stage is derived from the ObjectModelAssessment.aggregate_score via thresholds in src/fcc/objectmodel/evolution.py (FEDERATED ≥0.85, SEMANTIC ≥0.65, STRUCTURED ≥0.40). Check the weakest_dimensions(3) helper to see what's dragging the score down.

"My scenario runs in the wrong family order"

The FCC workflow graph (complete_24_node or extended_84) enforces phase ordering (Find → Create → Critique). Ensure your Investigator is in Find, Architect in Create, Shepherd in Critique. The phase assignment lives in the persona's fcc_phase field or is inferred from the workflow graph.

Further reading