Skip to content

Chapter 10: Ecosystem Case Studies

Learning Objectives

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

  1. Integrate the CTO ontology with FCC's object model layer.
  2. Federate AOME taxonomy data with FCC persona catalogs.
  3. Enrich CONSTEL knowledge graphs with FCC-derived entities.
  4. Design a cross-project unified search architecture.

The FCC Ecosystem

FCC operates within an ecosystem of 11 interrelated projects, each contributing specialized capabilities. Four projects are particularly important for advanced integration:

Project Abbreviation Role
Cloud Technology Ontology CTO Ontological backbone for domain modeling
Archetype Orchestration Meta-Engine AOME Archetype taxonomy and composition
Constellation Knowledge Graph CONSTEL Cross-domain knowledge federation
SkyParlour SP Visualization and interaction design

This chapter provides deep-dive case studies for each integration.

Case Study 1: CTO Ontology Integration

Background

The CTO project defines a comprehensive ontology for cloud technology domains. It provides a vocabulary of entities (services, capabilities, patterns) and relationships (depends-on, implements, extends) that FCC uses to ground its personas in domain reality.

Integration Architecture

FCC integrates with CTO through the fcc.objectmodel layer:

┌──────────────────┐     ┌──────────────────┐
│  FCC Personas    │     │  CTO Ontology    │
│  (YAML)          │     │  (OWL/RDF)       │
└────────┬─────────┘     └────────┬─────────┘
         │                        │
         ▼                        ▼
┌──────────────────┐     ┌──────────────────┐
│  ModelFacade     │     │  CTOFacadeAdapter │
│  (FCC)           │◄────│  (Bridge)         │
└────────┬─────────┘     └──────────────────┘
         │
         ▼
┌──────────────────┐
│  Unified Query   │
│  Interface       │
└──────────────────┘

VocabularyMapping

The VocabularyMapping dataclass maps FCC terms to CTO terms:

from fcc.objectmodel.mapping import VocabularyMapping

mapping = VocabularyMapping(
    source_namespace="fcc",
    target_namespace="cto",
    term_mappings={
        "persona": "cto:Agent",
        "workflow": "cto:Process",
        "deliverable": "cto:Artifact",
        "category": "cto:Domain",
        "fcc_phase": "cto:Phase",
    },
)

Querying Across Systems

With the bridge in place, queries can span both systems:

from fcc.objectmodel.facade import ModelFacade

facade = ModelFacade.from_registries(fcc_registry, cto_adapter)

# Find all entities related to "data engineering"
results = facade.search("data engineering", limit=20)
for r in results:
    print(f"  {r.namespace}:{r.id} - {r.name} ({r.entity_type})")

Evolution Assessment

The ObjectModelAssessment tracks how well FCC's object model aligns with CTO's ontology maturity:

from fcc.objectmodel.evolution import ObjectModelAssessment

assessment = ObjectModelAssessment.evaluate(fcc_registry, cto_adapter)
print(f"Alignment score: {assessment.alignment_score:.0%}")
print(f"Coverage gaps: {assessment.coverage_gaps}")

Case Study 2: AOME Taxonomy Federation

Background

AOME manages the 37 ecosystem archetypes and their composition rules. FCC's 102 personas are derived from these archetypes but add FCC- specific attributes (R.I.S.C.E.A.R., dimensions, constitutions). Federation ensures that changes in AOME flow to FCC and vice versa.

Federation Protocol

The federation protocol operates in three stages:

Stage 1: Entity Resolution

from fcc.federation.resolver import EntityResolver

resolver = EntityResolver()
resolver.register("fcc", fcc_registry)
resolver.register("aome", aome_catalog)

# Resolve an FCC persona to its AOME archetype
matches = resolver.resolve("fcc:research_catalyst")
# Returns: [("aome:researcher_archetype", 0.95)]

Stage 2: Change Tracking

from fcc.federation.tracker import ChangeTracker

tracker = ChangeTracker()
tracker.track("aome", aome_catalog_v2)

changes = tracker.changes_since("aome", version="2.3.0")
print(f"New archetypes: {changes.additions}")
print(f"Modified archetypes: {changes.modifications}")
print(f"Removed archetypes: {changes.removals}")

Stage 3: Namespace Reconciliation

from fcc.federation.namespace import NamespaceRegistry

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

# Generate qualified name
qualified = ns.qualify("fcc", "research_catalyst")
# Returns: "https://fcc.example.org/research_catalyst"

Bidirectional Sync

When an AOME archetype is updated, the federation pipeline:

  1. Detects the change via ChangeTracker.
  2. Resolves affected FCC personas via EntityResolver.
  3. Generates update proposals (additions/modifications to R.I.S.C.E.A.R.).
  4. Submits proposals for human review via CollaborationEngine.

When an FCC persona is added, the reverse flow creates a proposal for a new AOME archetype.

Case Study 3: CONSTEL Knowledge Graph Enrichment

Background

CONSTEL maintains a cross-domain knowledge graph that spans all ecosystem projects. FCC contributes persona, workflow, and simulation data as knowledge graph nodes and edges.

Building the FCC Knowledge Graph

from fcc.knowledge.builders import build_full_fcc_graph
from fcc.personas.registry import PersonaRegistry

registry = PersonaRegistry.from_package_data()
graph = build_full_fcc_graph(registry)

print(f"Nodes: {graph.node_count}")
print(f"Edges: {graph.edge_count}")
print(f"Node types: {graph.node_types}")

Enrichment Pipeline

The enrichment pipeline adds FCC-derived data to CONSTEL:

  1. Export. Serialize the FCC graph to JSON-LD.
  2. Map. Apply vocabulary mappings to align FCC terms with CONSTEL terms.
  3. Merge. Add FCC nodes and edges to the CONSTEL graph, resolving duplicates via entity resolution.
  4. Validate. Run consistency checks to ensure the merged graph has no dangling references.
from fcc.knowledge.serializers import JsonLdSerializer
from fcc.knowledge.federation import FederatedKnowledgeGraph

# Export FCC graph
serializer = JsonLdSerializer()
fcc_jsonld = serializer.serialize(graph)

# Merge with CONSTEL
federated = FederatedKnowledgeGraph()
federated.add_namespace("fcc", graph)
federated.add_namespace("constel", constel_graph)

# Cross-namespace query
results = federated.query(
    node_type="persona",
    namespace="fcc",
    related_namespace="constel",
)

Ontology Alignment

FCC's ontology (FCCOntology) defines 9 node types and 9 edge types. CONSTEL's ontology is broader. Alignment requires:

  • Node type mapping. FCC persona -> CONSTEL agent; FCC workflow -> CONSTEL process.
  • Edge type mapping. FCC collaborates_with -> CONSTEL interacts_with.
  • Property mapping. FCC riscear.role -> CONSTEL agent.capability.

Serialization Formats

Format Use Case Library
OWL Formal ontology definition rdflib
RDF/Turtle Machine-readable graph export rdflib
SKOS Taxonomy and vocabulary export rdflib
JSON-LD Web-friendly linked data Built-in

The Problem

Each ecosystem project maintains its own data store:

  • FCC: Persona YAML + workflow JSON.
  • CTO: OWL ontology files.
  • AOME: Archetype catalog.
  • CONSTEL: Knowledge graph database.

Users need to search across all projects with a single query.

Architecture

┌─────────────────────────────────────────────────┐
│                 Unified Search                   │
│           fcc.search + federation                │
├──────────┬──────────┬──────────┬────────────────┤
│ FCC      │ CTO      │ AOME     │ CONSTEL        │
│ Persona  │ Ontology │ Archetype│ Knowledge      │
│ Index    │ Index    │ Index    │ Graph Index    │
└──────────┴──────────┴──────────┴────────────────┘

Implementation

Step 1: Build Per-Project Indices

from fcc.search.persona_index import PersonaSearchIndex
from fcc.search.embeddings import MockEmbeddingProvider

provider = MockEmbeddingProvider()
fcc_index = PersonaSearchIndex(provider)
fcc_index.build(registry)

Step 2: Register in Federation

from fcc.federation.registry import FederationRegistry

fed = FederationRegistry()
fed.register_index("fcc", fcc_index)
fed.register_index("cto", cto_index)
fed.register_index("aome", aome_index)
fed.register_index("constel", constel_index)

Step 3: Unified Query

results = fed.search("data engineering pipeline")
for result in results:
    print(f"  [{result.namespace}] {result.name} (score: {result.score:.3f})")

Ranking and Deduplication

Cross-project search requires:

  • Score normalization. Different indices may produce scores on different scales. Normalize to [0, 1] before merging.
  • Deduplication. The same entity may appear in multiple indices (e.g., a persona in both FCC and AOME). Use entity resolution to merge duplicate results.
  • Namespace weighting. Allow users to prioritize results from specific namespaces (e.g., prefer FCC results when searching for personas).

Integration Checklist

Integration Point Status Module
CTO ontology bridge Available fcc.objectmodel.cto_bridge
AOME entity resolution Available fcc.federation.resolver
CONSTEL KG enrichment Available fcc.knowledge.federation
Unified search Available fcc.search + fcc.federation
Vocabulary mapping Available fcc.objectmodel.mapping
Change tracking Available fcc.federation.tracker
Namespace registry Available fcc.federation.namespace

Lab Exercise

Exercise 10.1: Build a Cross-Project Assessment

  1. Load the FCC persona registry and a mock CTO adapter.
  2. Run ObjectModelAssessment.evaluate().
  3. Inspect alignment scores and coverage gaps.

Exercise 10.2: Federated Knowledge Graph Query

  1. Build the full FCC knowledge graph.
  2. Serialize to JSON-LD.
  3. Create a FederatedKnowledgeGraph with two namespaces.
  4. Run a cross-namespace query.

Exercise 10.3: Unified Search Across Projects

  1. Build persona and action search indices.
  2. Register both in a FederationRegistry.
  3. Search for "data engineering" and compare results across namespaces.

Summary

  • CTO integration provides ontological grounding for FCC personas through vocabulary mapping and the CTOFacadeAdapter.
  • AOME federation enables bidirectional sync of archetypes and personas with change tracking and entity resolution.
  • CONSTEL enrichment adds FCC-derived knowledge graph nodes to the cross-domain graph via JSON-LD serialization and federated merging.
  • Unified search combines per-project indices with score normalization, deduplication, and namespace weighting for cross-ecosystem queries.

Next: This concludes Book 3 and the FCC book series. For hands-on practice, proceed to the Jupyter notebooks (01-23) and the FCC Guidebook.

Key Takeaways

  • This chapter covered the essential concepts of Chapter 10: Ecosystem Case Studies.
  • Understanding these patterns is critical for effective FCC framework usage.
  • Apply these concepts alongside the companion notebooks and Streamlit apps for hands-on reinforcement.

Cross-References