Chapter 26: Persona Evolution and Archetype Lifecycle¶

New in v1.3.3. Previous chapters introduced what personas are (ch03 R.I.S.C.E.A.R., ch04 dimensions) and how they collaborate (ch08 collaboration engine). This chapter asks when personas change — how they mature over their lifecycle, how archetype families behave as stable attractors, and how champion promotion reshapes a team.

Why persona evolution matters¶

The 147 personas that ship with FCC are not frozen definitions. Every core persona was authored at one stage, matured through others, and — for four of them — promoted to a champion. When an adopter adds a custom persona, it re-enacts this lifecycle in miniature: a rough YAML stub grows cross-references, gains a discernment profile, acquires vocabulary mappings, and — if the team needs it — rises to champion.

Evolution matters because:

It makes quality legible. A STRUCTURED persona is distinguishable from a SEMANTIC one by inspection.
It gates automation. Model cards, compliance audits, and federated knowledge graphs all require the persona to be at SEMANTIC or higher.
It organises governance. Quality gates in src/fcc/data/governance/quality_gates.yaml attach to evolution steps.
It surfaces champion candidates. Promotion isn't arbitrary — it's a measured transition.

EvolutionStage as a first-class modeling primitive¶

The enum at src/fcc/objectmodel/evolution.py defines four stages:

class EvolutionStage(Enum):
    FOUNDATIONAL = "foundational"
    STRUCTURED = "structured"
    SEMANTIC = "semantic"
    FEDERATED = "federated"

Each stage has an ordinal, a description, and next_stage() / previous_stage() walkers. Stage classification is threshold-driven:

# src/fcc/objectmodel/evolution.py
_STAGE_THRESHOLDS = [
    (EvolutionStage.FEDERATED, 0.85),
    (EvolutionStage.SEMANTIC, 0.65),
    (EvolutionStage.STRUCTURED, 0.40),
    (EvolutionStage.FOUNDATIONAL, 0.0),
]

An ObjectModelAssessment aggregates dimension scores and assigns a stage based on the aggregate. Persona-level assessments use the same mechanism: score the persona on six dimensions (see next section), take the mean, classify.

from fcc.objectmodel.evolution import (
    EvolutionStage, DimensionScore, ObjectModelAssessment
)

a = ObjectModelAssessment(
    model_name="TTS",
    dimensions=(
        DimensionScore("riscear_completeness", 0.80),
        DimensionScore("collaborators_min_3", 0.90),
        DimensionScore("discernment_full", 0.70),
        DimensionScore("cross_reference_listed", 0.50),
        DimensionScore("vocabulary_resolvable", 0.40),
        DimensionScore("federation_resolved", 0.10),
    ),
)
print(a.stage)         # EvolutionStage.SEMANTIC
print(a.gap_to_next()) # 0.3 — gap to FEDERATED threshold 0.85

The five-stage lifecycle (four named + one terminal)¶

Though the enum defines four stages, in practice personas traverse five meaningful states: DRAFT (pre-registry), then the four enum stages.

The flowchart below traces the five-state persona lifecycle — DRAFT, FOUNDATIONAL, STRUCTURED, SEMANTIC, FEDERATED — plus the dashed championship branch that peels off from SEMANTIC.

flowchart LR
    D[DRAFT<br/>off-registry] --> F[FOUNDATIONAL<br/>≤0.40]
    F --> S[STRUCTURED<br/>0.40-0.65]
    S --> SM[SEMANTIC<br/>0.65-0.85]
    SM --> FE[FEDERATED<br/>≥0.85]
    SM -.->|championship branch| CH[Champion<br/>category=champion]

In practice, most adopter-contributed personas sit at STRUCTURED for some time before accumulating the cross-references and vocabulary mappings needed for SEMANTIC.

DRAFT¶

A new persona YAML in a scratch file. Not yet loaded. Typically appears as a single-sentence role description.

FOUNDATIONAL¶

Loaded into the registry but missing components. The model-card generator will refuse to produce a non-boilerplate card. fcc validate --personas emits warnings.

STRUCTURED¶

Full R.I.S.C.E.A.R. block, archetype assigned, at least 3 collaborators. This is the minimum bar for inclusion in the core-102 personas.

SEMANTIC¶

Cross-reference entries, full discernment matrix, dimension profile, and vocabulary-resolvable role skills. EU AI Act risk category assigned.

FEDERATED¶

Cross-project entity resolution, vocabulary mappings resolving across 2+ ecosystems, NIST AI RMF mapping, change-tracking history.

Archetype families as stable attractors¶

The six archetype families (Shepherd, Quant, Investigator, Architect, Storyteller, Safety Engineer) behave as stable attractors across evolution. A persona rarely changes family as it matures — the deep orientation (stewardship vs. analysis vs. audit vs. design vs. narrative vs. safety) is set early.

The flowchart below separates what stays stable across evolution (archetype family) from what changes frequently (category, collaborators, discernment matrix, vocabulary mappings).

flowchart TB
    subgraph "Stable across evolution"
      AF[Archetype Family]
    end
    subgraph "Changes frequently"
      C[Category]
      RC[role_collaborators]
      DM[Discernment Matrix]
      VM[Vocabulary Mappings]
    end
    AF -.->|informs| DM
    AF -.->|constrains| RC
    C -->|migrates| C2[Category-prime]

This is why family transitions are documented as exceptional events, while category and collaborator churn is treated as routine.

Family transitions do occur but are rare — documented examples include:

AEA (AI Ethics Auditor): Investigator → Shepherd during v1.2.0 retrofit.
DGS (Data Governance Specialist): Architect → Shepherd.
IRE (Insight Reporter): Quant → Storyteller.

When a family transition occurs, the archetype field in YAML must change and docs/personas/archetype-families.md must be regenerated.

Champion promotion as a special-case transition¶

A champion is a persona that orchestrates a team of base personas. Promotion is marked by two fields:

- id: RCHM
  category: champion
  champion_of: RC
  orchestrates: [RC, CIA, STE, RIC]

The flowchart below sketches a concrete champion-promotion example: RC is promoted to RCHM, which then orchestrates RC, CIA, STE, and RIC.

flowchart LR
    RC[RC · Research Crafter] -->|champions promotion| RCHM[RCHM · Research Crafter Champion]
    RCHM -->|orchestrates| RC
    RCHM -->|orchestrates| CIA
    RCHM -->|orchestrates| STE
    RCHM -->|orchestrates| RIC

This coexistence is why the registry tracks champion_of as an identity pointer rather than a replacement flag.

Promotion is a one-way transition and only fires when:

The base persona is at SEMANTIC or higher.
It appears in 3+ role_collaborators lists as upstream.
Its outputs feed into 2+ FCC phases (Find, Create, Critique).

The framework ships four champions: RCHM (Research), BCHM (Blueprint), RBCH (Runbook), UGCH (User Guide). Each was promoted at v1.0 during the core-102 consolidation.

Cross-reference matrix growth as evolution evidence¶

The cross-reference matrix at src/fcc/data/personas/cross_reference.yaml is a directional graph of upstream/downstream/peer relationships. The density of entries for a persona is one of the strongest evolution signals.

Persona	Cross-ref entries	Stage
Fresh stub	0	FOUNDATIONAL
Core persona v1	3–5	STRUCTURED
Core persona v2	5–10	SEMANTIC
Federated persona	10+ across ecosystems	FEDERATED

from fcc.personas.cross_reference import CrossReferenceMatrix
from fcc._resources import get_personas_dir

matrix = CrossReferenceMatrix.from_yaml(get_personas_dir() / "cross_reference.yaml")
entry = matrix.for_persona("RC")
print(len(entry.upstream), len(entry.downstream), len(entry.peers))

Quality gates that enforce evolution discipline¶

Quality gates in src/fcc/data/governance/quality_gates.yaml enforce transitions. Each gate blocks promotion past a named stage:

Gate	Blocks past
`persona.riscear.completeness`	FOUNDATIONAL
`persona.archetype.assigned`	FOUNDATIONAL
`persona.role_collaborators.min_3`	STRUCTURED
`persona.discernment.full_6_traits`	STRUCTURED
`persona.cross_reference.listed`	SEMANTIC
`persona.vocabulary.resolvable`	SEMANTIC
`persona.federation.resolved`	SEMANTIC → FEDERATED

Gates fire automatically during fcc validate --personas and during the compliance pipeline.

The flowchart below summarises the quality-gate signals that control each evolution step, labelling the edges with the specific gate bundles (RISCEAR, archetype, collaborators, discernment, xref, vocab) they enforce.

flowchart LR
    F[FOUNDATIONAL] -->|riscear + archetype| S[STRUCTURED]
    S -->|collaborators + discernment| SM[SEMANTIC]
    SM -->|xref + vocab| FE[FEDERATED]

The AND semantics are why a persona with full R.I.S.C.E.A.R. but no archetype remains stuck at FOUNDATIONAL — one missing gate is enough to block promotion.

Lab Exercise 26.1 — Evolve a custom persona through 3 stages¶

Goal. Take a DRAFT persona through FOUNDATIONAL → STRUCTURED → SEMANTIC using CLI signals at each step.

Setup¶

source .venv/bin/activate
mkdir -p ./scratch
cp src/fcc/data/personas/core_personas.yaml scratch/my_persona.yaml
# Edit scratch/my_persona.yaml — keep only a single new persona stub

Step 1: DRAFT → FOUNDATIONAL¶

Add a minimal persona:

- id: TTS
  name: Test Triage Specialist
  role_title: Test Triage Specialist
  category: devops
  riscear:
    role: Analyse failing tests and classify failure modes.

Run:

fcc validate --personas --file scratch/my_persona.yaml
fcc model-card generate --persona TTS --out scratch/tts-foundational.md

The card will be boilerplate — this is the FOUNDATIONAL signal.

Step 2: FOUNDATIONAL → STRUCTURED¶

Fill out all 10 R.I.S.C.E.A.R. components, assign archetype: The Test Detective, add role_collaborators: [DVE, PBD, QGD]. Re-run:

fcc validate --personas --file scratch/my_persona.yaml
fcc model-card generate --persona TTS --out scratch/tts-structured.md

The card now carries differentiated content — STRUCTURED achieved.

Step 3: STRUCTURED → SEMANTIC¶

Add discernment scores, add cross-reference entries to scratch/cross_reference_delta.yaml, and add vocabulary mappings under scratch/vocab/. Re-run validation and model-card generation. The card should now embed discernment matrix, dimension profile, and cross-reference upstream/downstream listings.

Expected final tree¶

scratch/
├── my_persona.yaml             # SEMANTIC-stage persona
├── cross_reference_delta.yaml  # xref entries for TTS
├── vocab/                      # vocabulary mappings
├── tts-foundational.md
├── tts-structured.md
└── tts-semantic.md             # this is the target

Lab Exercise 26.2 — Design a champion team¶

Goal. Promote TTS from Lab 26.1 to a champion orchestrating 3 base personas.

Step 1: Define the champion¶

- id: TTCH
  name: Test Triage Specialist Champion
  category: champion
  champion_of: TTS
  orchestrates: [TTS, DVE, QGD]
  riscear:
    role: >-
      Orchestrate test triage across DevOps, pipeline builders, and data
      quality. Synthesise failure reports into a unified weekly digest.
    style: Orchestration-focused, synthesis-driven, cross-team coordination.
    archetype: The Triage Director
    role_collaborators:
      - Orchestrates Test Triage Specialist (TTS) for root-cause analysis
      - Orchestrates DevOps Engineer (DVE) for pipeline fixes
      - Orchestrates Quality Guardian (QGD) for data regression checks
      - Hands off weekly digest to Executive Communicator (EC)

Step 2: Verify¶

fcc validate --personas --file scratch/my_persona.yaml
fcc personas show-champions
# Should list TTCH along with RCHM, BCHM, RBCH, UGCH.

Step 3: Visualise the team¶

The flowchart below visualises the TTCH champion team built in the lab, with orchestration edges to TTS, DVE, and QGD and a handoff edge to EC.

flowchart LR
    TTCH[TTCH · Champion] -->|orchestrates| TTS[TTS · Base]
    TTCH -->|orchestrates| DVE
    TTCH -->|orchestrates| QGD
    TTCH -->|hands off to| EC[EC · Storyteller]

This split is what lets the simulation engine route work through the orchestrated set while preserving the narrative handoff for reporting.

Step 4: Run a simulation¶

fcc simulate --scenario workshop-cross-family-demo --champion TTCH

The simulation engine should route work through TTCH and its orchestrated team.

Knowledge Check¶

(MC) Which EvolutionStage corresponds to an aggregate score of 0.62? a. FOUNDATIONAL b. STRUCTURED c. SEMANTIC d. FEDERATED
(MC) What is the minimum number of role_collaborators for STRUCTURED? a. 0 b. 1 c. 3 d. 5
(MC) Which family is most likely described by "authoritative, risk-averse, audit-ready"? a. Quant b. Shepherd c. Architect d. Storyteller
(MC) A persona appears in 4 collaborator lists as upstream, has its outputs consumed in both Find and Create phases, and is at SEMANTIC stage. This persona is a candidate for: a. Family transition b. Champion promotion c. Deprecation d. Vertical migration
(MC) Which file lists the four built-in champions? a. src/fcc/data/personas/champions.yaml b. src/fcc/data/personas/cross_reference.yaml c. src/fcc/personas/registry.py d. docs/personas/archetype-families.md
(Short) Explain why archetype is considered a stable attractor and category is not.
(Short) Describe two evolution signals that distinguish SEMANTIC from FEDERATED.
(Short) Given a persona whose expected_output is "findings report with citations," which family is it most likely in, and why?
(Short) Why does champion promotion require SEMANTIC stage as a precondition?
(Short) Name one quality gate that blocks promotion past STRUCTURED and explain what it checks.

Answers¶

b (STRUCTURED, 0.40–0.65)
c (3)
b (Shepherd)
b (Champion promotion)
a (champions.yaml)
Archetype reflects deep orientation (stewardship, analysis, audit, design, narrative, safety) that rarely changes. Category reflects current organisational placement which migrates as scope expands.
SEMANTIC has cross-reference entries + full discernment. FEDERATED adds cross-ecosystem vocabulary resolution + NIST/EU AI Act mapping + change tracking.
Investigator — findings report with citations is the Investigator's signature Expected Output.
SEMANTIC is when the persona is cross-referenced + discernment-scored — this is the baseline for safely orchestrating others.
persona.role_collaborators.min_3 checks that at least 3 collaborator IDs are listed; or persona.discernment.full_6_traits checks all 6 traits are scored. Either is acceptable.