Governance and Champion Patterns

This tutorial covers two specialized relationship patterns in the FCC cross-reference matrix: governance oversight and champion orchestration. Both carry authority beyond simple handoffs, and understanding their mechanics is essential for building compliant, well-orchestrated workflows.

The Governance Pipeline

Governance relationships represent oversight, compliance reporting, and authority to block downstream progress. In the FCC framework, governance flows converge on GCA (Governance Compliance Auditor), which then reports to the stakeholder hub.

DGS -> PTE -> AMS -> GCA -> CO

graph LR
    DGS[DGS: Data Governance] -->|handoff| PTE[PTE: Privacy Taxonomy]
    PTE -->|handoff| AMS[AMS: Anti-fact Mitigation]

    DGS -->|governance| GCA[GCA: Governance Compliance]
    PTE -->|governance| GCA
    AMS -->|governance| GCA

    GCA -->|handoff| CO[CO: Collaboration Orchestrator]

    style DGS fill:#FCE4EC,stroke:#C62828
    style PTE fill:#FCE4EC,stroke:#C62828
    style AMS fill:#FCE4EC,stroke:#C62828
    style GCA fill:#E8F5E9,stroke:#2E7D32
    style CO fill:#F3E5F5,stroke:#6A1B9A

DGS provides data governance context and integration data. It hands off schema data to PTE for privacy classification. PTE classifies sensitive content and hands context to AMS for factual accuracy validation.

All three governance personas -- DGS, PTE, and AMS -- report compliance status to GCA using governance-type relationships. GCA then reports aggregated governance status to CO for coordination planning.

The Governance Entries

# DGS reports to GCA
- source_id: DGS
  target_id: GCA
  relationship_type: governance
  interaction: Reports compliance status for governance audit
  strength: primary

# PTE reports to GCA
- source_id: PTE
  target_id: GCA
  relationship_type: governance
  interaction: Reports privacy compliance for governance audit
  strength: primary

# AMS reports to GCA
- source_id: AMS
  target_id: GCA
  relationship_type: governance
  interaction: Reports validation results for governance compliance
  strength: primary

Governance Feedback Loops

Beyond the governance pipeline, governance personas also provide feedback to core personas:

from fcc.personas.cross_reference import CrossReferenceMatrix

matrix = CrossReferenceMatrix.from_yaml("data/personas/cross_reference.yaml")

# AMS provides feedback to both DE and BC
for entry in matrix.downstream("AMS"):
    if entry.relationship_type == "feedback":
        print(f"  AMS -> {entry.target_id}: {entry.interaction}")

Output:

  AMS -> DE: Reviews documentation for factual accuracy
  AMS -> PTE: Receives classification context for sensitive content
  AMS -> BC: Provides quality feedback on blueprint accuracy

This dual role -- reporting to GCA for formal governance and providing feedback to content creators -- gives governance personas broad influence across the workflow.

Why Governance is Distinct from Handoff

Attribute	Handoff	Governance
Purpose	Transfer a deliverable for continuation	Report compliance status for oversight
Ownership	Transfers to target	Remains with source
Authority	None -- target simply receives	Target can block progress
Flow direction	Forward (toward delivery)	Lateral (toward oversight)
Example	RC -> BC: delivers research	DGS -> GCA: reports compliance

A handoff says "here is work for you to continue." A governance relationship says "here is evidence that I am compliant -- you have authority to approve or block."

Champion Orchestration

Champions are elevated personas that coordinate teams of base personas into unified deliverable packages. Each champion has exactly one champion-of entry plus several handoff entries to its orchestrated team members.

The Four Champions

Champion	Base Persona	Orchestrates	Phase
RCHM	RC (Research Crafter)	RC, CIA, STE, RIC	Find
BCHM	BC (Blueprint Crafter)	BC, BV, UMC, RIC	Create
UGCH	UG (User Guide Crafter)	UG, SCP, EC	Critique/Publish
RBCH	RB (Runbook Crafter)	RB, GCA, TS	Operations

Champion Entry Structure

Each champion has two types of entries to its base persona:

# 1. The champion-of relationship (defines the champion architecture)
- source_id: RCHM
  target_id: RC
  relationship_type: champion-of
  interaction: Champions and elevates the Research Crafter persona
  strength: primary

# 2. The orchestration handoff (defines the work coordination)
- source_id: RCHM
  target_id: RC
  relationship_type: handoff
  interaction: Orchestrates core research activities
  strength: primary

The champion-of entry is architectural -- it declares the relationship. The handoff entry is operational -- it describes the actual work coordination.

Why Champion-of is Distinct from Handoff

Attribute	Handoff	Champion-of
Purpose	Transfer a specific deliverable	Declare an ongoing orchestration relationship
Duration	One-time transfer	Persistent throughout workflow
Multiplicity	Many handoffs per persona	Exactly one champion-of per champion
Ownership	Transfers	Base persona retains deliverable ownership
Example	RC -> BC: delivers inventory	RCHM -> RC: elevates the persona

A handoff says "take this artifact and continue." A champion-of relationship says "I am responsible for coordinating your work with others into a unified package."

Cross-Champion Workflow

Champions do not operate in isolation -- they hand off to each other in a defined pipeline.

RCHM -> BCHM -> RBCH

graph LR
    RCHM[RCHM: Research Champion] -->|research_package| BCHM[BCHM: Blueprint Champion]
    BCHM -->|blueprint_for_ops| RBCH[RBCH: Operations Champion]
    BCHM -->|blueprint_package| DE[DE: Documentation Evangelist]
    DE -->|approved_for_publishing| UGCH[UGCH: User Experience Champion]

    BCHM -.->|feedback| RCHM
    RBCH -.->|feedback| BCHM

    style RCHM fill:#FFF8E1,stroke:#F9A825
    style BCHM fill:#FFF8E1,stroke:#F9A825
    style UGCH fill:#FFF8E1,stroke:#F9A825
    style RBCH fill:#FFF8E1,stroke:#F9A825
    style DE fill:#FFF3E0,stroke:#EF6C00

Forward flow (handoffs):

1. RCHM -> BCHM: Hands off unified research package to the Create phase
2. BCHM -> DE: Hands off blueprint packages for critique
3. BCHM -> RBCH: Hands off blueprints for operational implementation
4. DE -> UGCH: Hands off approved content for publishing orchestration

Reverse flow (feedback):

1. BCHM -> RCHM: Receives unified research packages (confirms receipt, requests clarification)
2. RBCH -> BCHM: Receives blueprints for operational implementation (reports operational feasibility)

Querying Champion Chains

from fcc.personas.cross_reference import CrossReferenceMatrix

matrix = CrossReferenceMatrix.from_yaml("data/personas/cross_reference.yaml")

# Find all champion-to-champion interactions
champion_ids = {"RCHM", "BCHM", "UGCH", "RBCH"}
for entry in matrix:
    if entry.source_id in champion_ids and entry.target_id in champion_ids:
        print(f"  {entry.source_id} -> {entry.target_id} "
              f"[{entry.relationship_type}]: {entry.interaction}")

Output:

  RCHM -> BCHM [handoff]: Hands off unified research package to Create phase
  BCHM -> RCHM [feedback]: Receives unified research packages
  BCHM -> RBCH [handoff]: Hands off blueprints for operational implementation
  RBCH -> BCHM [feedback]: Receives blueprints for operational implementation

Governance x Champion Interaction

Champions and governance personas intersect at RBCH (Runbook Crafter Champion), which orchestrates GCA (Governance Compliance Auditor).

graph TD
    RBCH[RBCH: Operations Champion] -->|orchestrate_compliance| GCA[GCA: Governance Compliance]
    RBCH -->|orchestrate_runbooks| RB[RB: Runbook Crafter]
    RBCH -->|orchestrate_tracing| TS[TS: Traceability Specialist]

    DGS[DGS] -->|governance| GCA
    PTE[PTE] -->|governance| GCA
    AMS[AMS] -->|governance| GCA

    GCA -->|handoff| CO[CO: Collaboration Orchestrator]

    style RBCH fill:#FFF8E1,stroke:#F9A825
    style GCA fill:#E8F5E9,stroke:#2E7D32
    style RB fill:#E3F2FD,stroke:#1565C0
    style TS fill:#E3F2FD,stroke:#1565C0
    style DGS fill:#FCE4EC,stroke:#C62828
    style PTE fill:#FCE4EC,stroke:#C62828
    style AMS fill:#FCE4EC,stroke:#C62828
    style CO fill:#F3E5F5,stroke:#6A1B9A

This creates a dual-authority pattern:

• RBCH orchestrates GCA as part of the operations team (champion authority)
• DGS, PTE, AMS report to GCA as a governance authority (governance authority)

GCA acts as a bridge between the champion orchestration pipeline and the governance compliance pipeline. It receives orchestration direction from RBCH (when to audit, what scope) and governance reports from DGS/PTE/AMS (compliance status).

Querying the Intersection

# All entries involving GCA
gca_upstream = matrix.upstream("GCA")
gca_downstream = matrix.downstream("GCA")

print("GCA receives from:")
for entry in gca_upstream:
    print(f"  {entry.source_id} [{entry.relationship_type}]: {entry.interaction}")

print("\nGCA sends to:")
for entry in gca_downstream:
    print(f"  {entry.target_id} [{entry.relationship_type}]: {entry.interaction}")

Output:

GCA receives from:
  CIA [handoff]: Reports coverage gaps for compliance review
  TS [handoff]: Reports compliance gaps for governance audit
  BV [handoff]: Submits compliance verification results
  DGS [governance]: Reports compliance status for governance audit
  PTE [governance]: Reports privacy compliance for governance audit
  AMS [governance]: Reports validation results for governance compliance
  RBCH [handoff]: Orchestrates compliance auditing

GCA sends to:
  DE [feedback]: Audits documentation for governance compliance
  BV [feedback]: Receives validation results for compliance review
  TS [feedback]: Reviews traceability for compliance completeness
  CO [handoff]: Reports governance status for coordination

Designing New Governance Relationships

When adding governance relationships for new personas:

1. Identify the oversight authority. In most cases this is GCA, but you can create domain-specific governance authorities.
2. Define what compliance means. The interaction field should describe what evidence is being reported.
3. Set strength to primary unless the governance relationship is advisory rather than blocking.
4. Add corresponding feedback entries from the governance authority back to content-producing personas.

# Example: adding a Security Compliance Officer (SCO) persona
- source_id: SCO
  target_id: GCA
  relationship_type: governance
  interaction: Reports security compliance status for governance audit
  strength: primary

- source_id: GCA
  target_id: SCO
  relationship_type: feedback
  interaction: Reviews security findings for compliance completeness
  strength: secondary

Designing New Champion Relationships

When adding a new champion persona:

1. Define the champion-of entry linking the champion to its base persona.
2. Define handoff entries from the champion to each orchestrated persona.
3. Define the inter-champion handoff connecting this champion to adjacent champions in the pipeline.
4. Define the feedback entry from the receiving champion back to this one.

# Example: adding a Testing Champion (TSCH) for TS
- source_id: TSCH
  target_id: TS
  relationship_type: champion-of
  interaction: Champions and elevates the Traceability Specialist persona
  strength: primary

- source_id: TSCH
  target_id: TS
  relationship_type: handoff
  interaction: Orchestrates traceability verification activities
  strength: primary

- source_id: TSCH
  target_id: BV
  relationship_type: handoff
  interaction: Orchestrates quality validation integration
  strength: primary

- source_id: RBCH
  target_id: TSCH
  relationship_type: handoff
  interaction: Hands off operational context for testing orchestration
  strength: primary

Next Steps

• Persona Interactions -- Comprehensive tutorial on reading and querying the matrix
• Champion Orchestration -- Workflow graph perspective on champion patterns
• Interaction Cookbook -- Recipes for common cross-reference patterns
• Cross-Reference Matrix Specification -- Full data model and tables