Chapter 22: Ecosystem Orchestration

Orchestrating multiple ecosystem projects requires coordination at the data, protocol, and governance layers. This chapter covers federation patterns, namespace management, change tracking, and cross-project workflow execution.

The flowchart below arranges the eleven ecosystem projects into three tiers — Core, Extensions, and Consumers — and shows the hard and dashed dependencies that bind them.

flowchart TB
    subgraph Tier1["Tier 1: Core"]
        FCC[FCC Agent Team Framework]
    end
    subgraph Tier2["Tier 2: Extensions"]
        CTO[CTO<br/>Ontology Backbone]
        AOME[AOME<br/>Archetype Taxonomy]
        CONSTEL[CONSTEL<br/>KG Federation]
        SKY[SkyParlour<br/>Visualization]
        DIST[Distiller<br/>Knowledge Extraction]
    end
    subgraph Tier3["Tier 3: Consumers"]
        PAOM[PAOM<br/>Project Management]
        P1[p1<br/>Portfolio Intel]
        AICOE[AI-CoE<br/>Governance]
    end

    FCC --> CTO
    FCC --> AOME
    FCC --> CONSTEL
    FCC --> SKY
    FCC --> DIST
    CTO --> PAOM
    AOME --> P1
    CONSTEL --> AICOE
    FCC -.->|Namespace Registry| CONSTEL
    FCC -.->|Entity Resolver| AOME

    style FCC fill:#2196F3,color:#fff
    style Tier1 fill:#e3f2fd
    style Tier2 fill:#f3e5f5
    style Tier3 fill:#e8f5e9

This tiered shape is why swapping a Tier 2 extension rarely breaks Tier 3 consumers — the dashed bindings isolate name resolution from concrete service bindings.

Ecosystem Overview

The FCC ecosystem comprises 11 projects, each with a defined role:

Project	Tier	Role
FCC	Core	Agent team framework
CTO	Core	Ontological backbone
AOME	Core	Archetype taxonomy
CONSTEL	Core	Knowledge graph federation
SkyParlour	Integration	Visualization platform
Distiller	Integration	Knowledge extraction
PAOM	Consumer	Project management bridge
p1	Consumer	Portfolio intelligence
AI-CoE	Governance	AI center of excellence

Federation Architecture

Federation enables cross-project data access without centralization:

┌─────────┐   ┌─────────┐   ┌─────────┐
│   FCC   │◄──│ Registry │──►│  AOME   │
└────┬────┘   └────┬────┘   └────┬────┘
     │             │              │
     ▼             ▼              ▼
┌─────────┐   ┌─────────┐   ┌─────────┐
│ FCC KG  │◄──│ Fed. KG │──►│ AOME KG │
└─────────┘   └─────────┘   └─────────┘

Namespace Registry

Each project registers a namespace URI:

from fcc.federation.namespace import NamespaceRegistry

ns = NamespaceRegistry()
ns.register("fcc", "https://fcc.example.org/")
ns.register("cto", "https://cto.example.org/")
ns.register("aome", "https://aome.example.org/")
ns.register("constel", "https://constel.example.org/")

The registry supports 11 ecosystem namespaces out of the box.

Entity Resolution

Cross-project entity resolution maps entities between namespaces:

from fcc.federation.resolver import EntityResolver

resolver = EntityResolver()
matches = resolver.resolve("fcc:research_catalyst")
# [("aome:researcher_archetype", 0.95)]

Resolution strategies: - Exact match on entity ID. - Name similarity using string distance. - Embedding similarity using semantic search.

Change Tracking

The ChangeTracker monitors modifications across projects:

from fcc.federation.tracker import ChangeTracker

tracker = ChangeTracker()
tracker.track("aome", aome_v2)
changes = tracker.changes_since("aome", version="2.3.0")

Change types: additions, modifications, removals, renames.

Cross-Project Workflow Patterns

Pattern 1: Enrichment Pipeline

Enrich FCC personas with CTO ontology data:

1. Load FCC personas.
2. For each persona, query CTO for related domain concepts.
3. Add CTO-derived metadata to persona profiles.
4. Validate enriched personas against schema.

Pattern 2: Taxonomy Sync

Synchronize AOME archetypes with FCC personas:

1. Detect changes in AOME via ChangeTracker.
2. Resolve affected FCC personas via EntityResolver.
3. Generate update proposals.
4. Submit for human review.

Pattern 3: Knowledge Aggregation

Aggregate knowledge from all projects into CONSTEL:

1. Export each project's knowledge graph to JSON-LD.
2. Apply vocabulary mappings.
3. Merge into the federated graph.
4. Run consistency validation.

Governance Across Projects

Multi-project governance requires:

• Shared quality gates enforced by the AI-CoE project.
• Cross-project constitutions that apply to federated entities.
• Audit trails that span project boundaries via the event bus.

Lab Exercise

Lab 22.1: Register 4 ecosystem namespaces and qualify entity names from each. Verify that qualified names use the correct URI prefix.

Lab 22.2: Set up a ChangeTracker with two project versions. Detect additions and modifications between versions.

Lab 22.3: Design a cross-project enrichment pipeline (pseudocode) that adds CTO domain tags to FCC personas.

Summary

• Federation enables cross-project data access through namespace registration, entity resolution, and change tracking.
• Three cross-project workflow patterns (enrichment, sync, aggregation) address common integration needs.
• Governance spans projects through shared quality gates, cross-project constitutions, and unified audit trails.