Chapter 6: Cross-Project Orchestration¶

Learning Objectives¶

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

Describe how FCC orchestrates work across AOME, CONSTEL, CTO, and Sky-Parlour.
Use EAIFC workflow graphs for multi-project scenarios.
Integrate AOME privacy classification into FCC workflows.
Leverage CONSTEL metadata indexing for cross-project discovery.
Bridge FCC's object model to CTO for enterprise system integration.

The figure below shows FCC dispatching EAIFC workflow tasks to AOME, CONSTEL, and CTO in parallel, then aggregating their results through the governance layer before handing the combined output to Sky-Parlour for stakeholder viewing.

flowchart TB
    subgraph FCC["FCC (Tier 1 Orchestrator)"]
        WF[EAIFC Workflow Graph]
        GOV[Governance Layer]
    end
    subgraph AOME_P["AOME"]
        PRIV[Privacy Classification]
    end
    subgraph CONSTEL_P["CONSTEL"]
        META[Metadata Indexing]
    end
    subgraph CTO_P["CTO"]
        ONT[Ontology Bridge]
    end
    subgraph SKY_P["Sky-Parlour"]
        VIZ[Stakeholder View]
    end

    WF -->|dispatch task| AOME_P
    WF -->|dispatch task| CONSTEL_P
    WF -->|dispatch task| CTO_P
    AOME_P -->|results| GOV
    CONSTEL_P -->|results| GOV
    CTO_P -->|results| GOV
    GOV -->|aggregated output| SKY_P

    style FCC fill:#e3f2fd
    style WF fill:#2196F3,color:#fff
    style GOV fill:#FF9800,color:#fff

Dispatch is explicit in the graph rather than implicit in library imports, which is what keeps FCC's Tier 1 status compatible with project autonomy in AOME, CONSTEL, and CTO.

The Orchestration Challenge¶

Single-project FCC deployments are self-contained: personas, workflows, and governance all operate within a single process. Multi-project deployments are fundamentally different. Each project has its own personas, its own knowledge graph, its own governance rules, and its own runtime. Orchestrating work across these boundaries requires a coordination layer that respects project autonomy while enabling collaborative workflows.

FCC serves as this coordination layer. As the Tier 1 project in the ecosystem, FCC defines the workflow structure, dispatches tasks to other projects, collects results, and applies governance across the combined output.

EAIFC Workflow Graphs¶

Ecosystem-Aware Inter-Framework Collaboration (EAIFC) workflow graphs extend the standard FCC graphs to include cross-project nodes. Where a standard node activates an FCC persona, an EAIFC node can activate a capability in any ecosystem project:

{
  "id": "eaifc_data_pipeline",
  "name": "Cross-Project Data Pipeline Review",
  "nodes": [
    {
      "id": "find_requirements",
      "persona_id": "domain_expert",
      "phase": "find",
      "project": "fcc"
    },
    {
      "id": "classify_data",
      "capability": "privacy_classification",
      "phase": "find",
      "project": "aome",
      "protocol": "a2a"
    },
    {
      "id": "create_pipeline",
      "persona_id": "data_pipeline_engineer",
      "phase": "create",
      "project": "fcc"
    },
    {
      "id": "index_metadata",
      "capability": "metadata_indexing",
      "phase": "create",
      "project": "constel",
      "protocol": "a2a"
    },
    {
      "id": "critique_compliance",
      "persona_id": "compliance_officer",
      "phase": "critique",
      "project": "fcc"
    }
  ],
  "edges": [
    {"from": "find_requirements", "to": "classify_data", "type": "forward"},
    {"from": "classify_data", "to": "create_pipeline", "type": "forward"},
    {"from": "create_pipeline", "to": "index_metadata", "type": "parallel"},
    {"from": "create_pipeline", "to": "critique_compliance", "type": "forward"},
    {"from": "critique_compliance", "to": "find_requirements", "type": "feedback"}
  ]
}

The key difference from standard graphs: nodes with "project": "aome" or "project": "constel" are executed via protocol integration (A2A), not by the local simulation engine.

AOME Integration¶

AOME provides privacy-aware object modeling. Its primary capabilities that FCC orchestrates:

Privacy Classification¶

Before FCC personas process data, AOME classifies the data's privacy level:

from fcc.protocols.a2a.client import A2AClient

aome_client = A2AClient(base_url="https://aome.example.org/a2a/")

classification = aome_client.send_task({
    "capability": "privacy_classification",
    "input": {
        "data_sample": artifact_text[:1000],
        "context": "FCC simulation artifact",
    },
})

print(f"Classification: {classification.output['level']}")
# "public", "internal", "confidential", or "restricted"

Privacy-Aware Governance¶

FCC's governance system uses AOME's classifications to enforce privacy rules:

# In a governance check
if aome_classification["level"] in ("confidential", "restricted"):
    # Apply strict data handling constitutions
    applicable_constitutions.append("data_privacy_strict")
    # Restrict federated access
    federation_access = "metadata_only"

This integration ensures that FCC workflows automatically adapt their governance posture based on the sensitivity of the data being processed.

AOME Plugin Personas¶

AOME contributes privacy-focused personas to FCC's catalog through the plugin system:

Privacy Officer: Reviews artifacts for PII and privacy violations.
Data Protection Analyst: Assesses data handling practices against regulations.
Consent Manager: Tracks and validates data consent requirements.

These personas operate as standard FCC personas but bring AOME's domain-specific privacy expertise.

CONSTEL Integration¶

CONSTEL manages metadata across the ecosystem. Its primary capabilities:

Metadata Indexing¶

When FCC produces artifacts, CONSTEL indexes their metadata for cross-project discovery:

constel_client = A2AClient(base_url="https://constel.example.org/a2a/")

constel_client.send_task({
    "capability": "index_metadata",
    "input": {
        "artifact_id": "fcc:artifact_001",
        "metadata": {
            "type": "finding",
            "persona": "research_analyst",
            "session": "session_42",
            "created_at": "2026-03-29T10:30:00Z",
            "tags": ["market_research", "saas"],
        },
    },
})

Cross-Project Discovery¶

Other projects can discover FCC artifacts through CONSTEL:

# From another project, discover FCC artifacts
results = constel_client.send_task({
    "capability": "discover",
    "input": {
        "query": "market research artifacts from FCC",
        "project_filter": "fcc",
        "type_filter": "finding",
    },
})

Lineage Tracking¶

CONSTEL tracks the lineage of artifacts across projects:

lineage = constel_client.send_task({
    "capability": "trace_lineage",
    "input": {
        "artifact_id": "fcc:artifact_001",
        "direction": "both",  # upstream and downstream
    },
})

for step in lineage.output["chain"]:
    print(f"{step['project']}:{step['artifact_id']} -> {step['relationship']}")

CTO Integration¶

The Chief Technology Object (CTO) bridge (src/fcc/objectmodel/cto_bridge.py) translates between FCC's dataclass-based models and CTO's canonical object model. This integration is essential when FCC operates within an enterprise that uses CTO as its standard object model.

The Facade Adapter¶

from fcc.objectmodel.cto_bridge import CTOFacadeAdapter, cto_available

if cto_available():
    adapter = CTOFacadeAdapter()

    # Translate an FCC persona to a CTO entity
    cto_entity = adapter.to_cto(fcc_persona)

    # Translate a CTO entity to an FCC persona
    fcc_persona = adapter.from_cto(cto_entity)

The Repository Adapter¶

from fcc.objectmodel.cto_bridge import CTORepositoryAdapter

repo = CTORepositoryAdapter(cto_connection)

# Store FCC artifacts in CTO's repository
repo.save(fcc_artifact)

# Retrieve FCC artifacts from CTO's repository
artifact = repo.get("artifact_001")

Vocabulary Mapping¶

FCC and CTO use different terminology for similar concepts. The VocabularyMapping (src/fcc/objectmodel/mapping.py) defines the translations:

from fcc.objectmodel.mapping import VocabularyMapping

mapping = VocabularyMapping(
    mappings={
        "persona": "agent",          # FCC "persona" = CTO "agent"
        "workflow": "process",        # FCC "workflow" = CTO "process"
        "artifact": "deliverable",    # FCC "artifact" = CTO "deliverable"
        "quality_gate": "checkpoint", # FCC "quality_gate" = CTO "checkpoint"
    }
)

Sky-Parlour Integration¶

Sky-Parlour provides the natural-language interface for the orchestration layer. Stakeholders can ask questions like:

"What simulations ran last week?"
"Which personas produced the most artifacts?"
"Show me all artifacts that failed governance review."

Sky-Parlour translates these questions into queries against FCC's knowledge graph and CONSTEL's metadata index, combining results into a human-readable response.

The integration is through MCP: Sky-Parlour uses FCC's MCP tools and resources to access persona catalogs, workflow graphs, and simulation traces.

Orchestration Patterns¶

Pattern 1: Sequential Delegation¶

FCC runs its workflow, delegating specific tasks to ecosystem projects as needed:

FCC Find -> AOME Classify -> FCC Create -> CONSTEL Index -> FCC Critique

Simple and predictable. Use when the cross-project interactions are well-defined.

Pattern 2: Parallel Fan-Out¶

FCC dispatches tasks to multiple projects simultaneously:

         --> AOME Classify ---
FCC Find --> CONSTEL Discover --> FCC Create --> FCC Critique
         --> CTO Validate ----

Faster for independent tasks. Use when projects do not depend on each other's outputs.

Pattern 3: Iterative Collaboration¶

FCC and another project exchange results iteratively until convergence:

FCC Create <-> AOME Review (iterate until privacy-compliant)

Use for compliance workflows where the first attempt rarely meets all requirements.

Error Handling¶

Cross-project orchestration introduces failure modes that do not exist in single-project workflows:

Network failures. A2A calls may fail due to network issues. The orchestration layer retries with exponential backoff.
Project unavailability. A project may be down for maintenance. The orchestration layer can skip optional cross-project nodes or pause until the project is available.
Schema mismatches. Different projects may evolve their schemas independently. The vocabulary mapping layer translates between versions.
Timeout. Cross-project tasks may take longer than expected. Configurable timeouts prevent indefinite blocking.

Key Takeaways¶

EAIFC workflow graphs extend standard FCC graphs with cross-project nodes.
AOME provides privacy classification and contributes privacy-focused personas.
CONSTEL indexes metadata and enables cross-project discovery and lineage tracking.
CTO bridges FCC's object model to enterprise canonical models via facade and repository adapters.
Sky-Parlour provides natural-language access to the orchestration layer.
Cross-project error handling requires retries, fallbacks, and vocabulary mapping.

Cross-References¶

Chapter 7: Docs from Code -- documentation intelligence
Chapter 5: Protocol Integration -- the transport layer for orchestration
FCC Guidebook, Chapter 10 -- cross-project reference
Notebook 11: Object Model Patterns -- hands-on CTO integration
Book 1, Chapter 6: Ecosystem Overview -- ecosystem context

← Chapter 5: Protocol Integration | Next: Chapter 7 -- Docs from Code →