Skip to content

Chapter 10: Cross-Project Integration

FCC does not exist in isolation. It is one component in a broader ecosystem of projects — each with its own domain, data model, and lifecycle. This chapter explains how FCC integrates with sibling projects through plugin-based bridging, the CTO bridge architecture, and the PAOM/AOME/CONSTEL dependency triangle.

The flowchart below shows the three-layer integration stack — abstract protocols, concrete bridges, and educational data — plus the PAOM/AOME/CONSTEL consumers that sit on top.

flowchart TB
    subgraph Layer1["Layer 1: Abstract Protocols"]
        OP[OntologyProvider]
        MP[MappingProvider]
        MatP[MaturityProvider]
    end
    subgraph Layer2["Layer 2: Concrete Bridge"]
        VL[Vocabulary Loader]
        MA[Maturity Assessor]
        CVM[Cross-Vocab Mapper]
    end
    subgraph Layer3["Layer 3: Educational Data"]
        SD[Sample Data]
        TU[Tutorials]
        RM[Reference Mappings]
    end

    FCC[FCC Framework] --> OP
    FCC --> MP
    FCC --> MatP
    OP --> VL
    MP --> CVM
    MatP --> MA
    VL --> SD
    CVM --> RM
    MA --> TU

    PAOM[PAOM] -.->|consumes personas| FCC
    AOME[AOME] -.->|provides taxonomy| FCC
    CONSTEL[CONSTEL] -.->|provides metadata| FCC

    style FCC fill:#2196F3,color:#fff
    style PAOM fill:#9C27B0,color:#fff
    style AOME fill:#4CAF50,color:#fff
    style CONSTEL fill:#FF9800,color:#fff

Keeping the protocol layer abstract is what lets adopters swap the bridge implementation — or replace it with a project-specific one — without touching FCC itself.

The Ecosystem Context

The FCC framework sits at the center of an ecosystem of 11+ projects. While FCC owns the Find-Create-Critique workflow and the R.I.S.C.E.A.R. specification, other projects consume and extend these capabilities:

  • PAOM (Persona-Aware Object Model) — consumes FCC personas for LLM routing and prompt engineering.
  • AOME (Adaptive Object Model Engine) — provides privacy taxonomy and adaptive data models that FCC governance can reference.
  • CONSTEL (Constellation Metadata Service) — supplies metadata and vocabulary services that FCC personas use for cross-vocabulary mapping.

FCC is the canonical authority for the FCC framework and R.I.S.C.E.A.R. spec. PAOM is a consumer, not the authority. See STRATEGIC_ARCHITECTURE_REVIEW.md for the full alignment document.

CTO Bridge: 3-Layer Design

The CTO (Common Technology Ontology) bridge connects FCC to enterprise ontology systems. It uses a three-layer architecture:

Layer 1: Abstract Protocols

The abstract layer defines protocol interfaces that any ontology system can implement. These protocols specify:

  • OntologyProvider — exposes vocabulary terms, relationships, and hierarchies.
  • MappingProvider — provides cross-vocabulary mappings between ontology systems.
  • MaturityProvider — reports maturity assessments for ontology elements.

FCC code depends only on these protocols, never on a specific ontology implementation. This makes the bridge portable across different enterprise ontology tools.

Layer 2: Concrete Bridge

The concrete bridge implements the abstract protocols for a specific ontology system. For the CTO, this includes:

  • Vocabulary loading from YAML/JSON definitions
  • Maturity assessment using a 5-level scale (Initial, Developing, Defined, Managed, Optimized)
  • Cross-vocabulary mapping with confidence scores

The concrete bridge is packaged as a plugin (see below) so it can be installed independently of the core FCC framework.

Layer 3: Educational Data

The educational layer provides sample data, tutorials, and reference mappings that demonstrate how the bridge works. This layer is used by the guidebook labs (see Lab 6 and Lab 7) and is packaged under src/fcc/data/objectmodel/.

AOME Integration

The AOME plugin (fcc-aome-plugin) integrates adaptive object model capabilities into FCC workflows:

  • Privacy taxonomy — AOME provides a structured privacy taxonomy that FCC governance uses for PII classification and data handling rules.
  • Adaptive schemas — AOME's adaptive data model allows FCC scenarios to define custom entity types at runtime without code changes.
  • Event bridge — AOME publishes events on the FCC event bus when privacy classifications change, triggering governance re-evaluation.

The integration follows the plugin architecture described in Chapter 5. AOME registers as a provider plugin type, exposing its taxonomy through the standard OntologyProvider protocol.

CONSTEL Integration

The CONSTEL plugin (fcc-constel-plugin) provides metadata and vocabulary services:

  • Vocabulary registry — CONSTEL maintains a registry of domain vocabularies that FCC personas can reference for consistent terminology.
  • Metadata enrichment — during the Find phase, CONSTEL enriches research artifacts with structured metadata (provenance, classification, relationships).
  • Cross-reference support — CONSTEL's vocabulary mappings feed into the FCC cross-reference matrix, enabling personas to discover related concepts across domains.

CONSTEL registers as both a provider plugin (for vocabulary access) and a subscriber plugin (to receive events when new artifacts are created).

The Dependency Triangle

The three plugins form a dependency triangle:

    PAOM
   /    \
  /      \
CONSTEL ← AOME

The dependencies are:

Source Target Type Description
PAOM AOME provides_llm PAOM provides LLM routing for AOME analysis
AOME CONSTEL provides_taxonomy AOME provides privacy taxonomy for metadata
CONSTEL PAOM provides_metadata CONSTEL provides metadata for persona engineering

These dependencies are declared in src/fcc/data/ecosystem/plugin_dependencies.yaml and validated by the cross-plugin orchestration system. The triangle is intentionally circular — each project provides a capability the others need, creating a cohesive ecosystem.

Breaking the Cycle

While the logical dependencies form a cycle, the runtime dependencies are acyclic. Each plugin operates independently and communicates through the event bus. The "dependency" is a data-flow relationship, not a code-level import dependency. This means:

  1. Each plugin can be installed and tested independently.
  2. Missing plugins degrade gracefully — the system logs warnings but continues.
  3. The event bus decouples publishers from subscribers.

Ecosystem Health Monitoring

FCC provides ecosystem health monitoring through:

  • Plugin interaction tracking — plugin_interactions.yaml records which plugins communicate and through what event types.
  • Dependency validation — the cross-plugin orchestration system validates that declared dependencies are satisfiable at startup.
  • Dashboard — the ecosystem dashboard (fcc dashboard ecosystem) displays plugin status, interaction counts, and dependency health.

The health monitoring system uses the observability layer (see Chapter 7) to collect metrics on plugin interactions, including message latency, error rates, and throughput.

Plugin-Based Bridging

All cross-project integration uses the FCC plugin system. The 10 plugin types relevant to integration are:

Plugin Type Integration Use
personas Add domain-specific personas from other projects
providers Expose ontology, vocabulary, or taxonomy services
subscribers React to events from other projects
governance Layer project-specific compliance rules
workflows Add cross-project workflow steps

To create a bridge plugin:

  1. Define the plugin class implementing the appropriate interface.
  2. Register event subscriptions for cross-project communication.
  3. Declare dependencies in plugin_dependencies.yaml.
  4. Test in isolation using the mock simulation engine.
  5. Validate integration using the cross-plugin orchestration tests.
from fcc.messaging.plugin_bridge import EventSubscriberPlugin
from fcc.messaging.events import EventType

class MyBridgePlugin(EventSubscriberPlugin):
    plugin_id = "my-bridge"
    subscriptions = [EventType.ARTIFACT_CREATED]

    def handle_event(self, event):
        # Forward artifact to external system
        ...

Integration Patterns

Three common integration patterns emerge from the ecosystem:

  1. Event Forwarding — a subscriber plugin listens for FCC events and forwards them to an external system (e.g., AOME privacy scan on artifact creation).
  2. Data Enrichment — a provider plugin enriches FCC artifacts with external data (e.g., CONSTEL metadata enrichment during Find phase).
  3. Governance Overlay — a governance plugin adds rules from an external compliance framework (e.g., PAOM-derived persona constraints).

For a hands-on example, see Lab 5 in the labs chapter.

Cross-Project Vocabulary Federation

While the plugin architecture handles runtime integration, projects also need to share vocabularies, resolve entities across namespaces, and federate knowledge graphs. The federation layer provides these capabilities.

NamespaceRegistry

Each ecosystem project registers a namespace to prevent ID collisions when entities from different projects are combined:

from fcc.federation import NamespaceRegistry

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

# Resolve a qualified name to its full URI
full_uri = ns.resolve("fcc:persona-RC")
# "https://fcc.example.org/persona-RC"

# List all registered namespaces
for prefix, uri in ns.all():
    print(f"  {prefix}: {uri}")

The NamespaceRegistry ensures that when a persona ID like RC appears in both FCC and PAOM, they are unambiguously identified as fcc:persona-RC and paom:agent-RC.

EntityResolver

The EntityResolver maps entities across namespaces using vocabulary mappings. This is essential when different projects use different terminology for the same concept:

from fcc.federation import EntityResolver

resolver = EntityResolver(namespace_registry=ns)

# Register cross-project mappings
resolver.add_mapping("fcc:persona-RC", "paom:agent-research-curator", confidence=0.95)
resolver.add_mapping("fcc:persona-SA", "paom:agent-solution-architect", confidence=0.92)
resolver.add_mapping("fcc:concept-governance", "aome:concept-compliance", confidence=0.80)

# Resolve an FCC entity to its PAOM equivalent
paom_id = resolver.resolve("fcc:persona-RC", target_ns="paom")
print(paom_id)  # "paom:agent-research-curator"

# List all mappings for an entity
mappings = resolver.mappings_for("fcc:persona-RC")
for m in mappings:
    print(f"  {m.target}: confidence={m.confidence}")

The EntityResolver integrates with the existing VocabularyMapping from the object model layer (see Chapter 2), extending it with namespace awareness and cross-project resolution.

FederationRegistry

The FederationRegistry provides a higher-level API that combines namespace management, entity resolution, and knowledge graph federation:

Component Responsibility
NamespaceRegistry Map prefixes to URIs, resolve qualified names
EntityResolver Map entities across namespaces with confidence scores
FederationRegistry Orchestrate federation across ecosystem projects
FederatedKnowledgeGraph Merge and query knowledge graphs from multiple projects 
from fcc.federation import FederationRegistry

federation = FederationRegistry(namespace_registry=ns, resolver=resolver)

# Register project graphs
federation.register_project("fcc", fcc_graph, version="1.0.1")
federation.register_project("paom", paom_graph, version="1.2.0")

# Query across all projects
stats = federation.stats()
print(f"Projects: {stats.project_count}")
print(f"Total entities: {stats.entity_count}")
print(f"Cross-project mappings: {stats.mapping_count}")

# Find cross-project relationships
cross_edges = federation.cross_project_edges()
for edge in cross_edges:
    print(f"  {edge.source} -> {edge.target} ({edge.edge_type})")

For hands-on exercises with the federation system, see Chapter 17: Knowledge Federation and Notebook 18: Unified Object Model & Federation.

Key Takeaways

  • FCC integrates with sibling projects (PAOM, AOME, CONSTEL) through a plugin-based bridge architecture.
  • The CTO bridge uses three layers: abstract protocols, concrete bridge, and educational data.
  • The PAOM/AOME/CONSTEL dependency triangle is logically circular but runtime-acyclic.
  • Ecosystem health is monitored through plugin interaction tracking and dashboards.
  • All cross-project integration uses the standard FCC plugin system and event bus.
  • Cross-project vocabulary federation uses NamespaceRegistry, EntityResolver, and FederationRegistry to unify entities across namespaces.