Skip to content

Chapter 8: Scaling to Enterprise

Learning Objectives

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

  1. Identify the architectural changes needed to scale FCC from a single-team tool to an enterprise platform.
  2. Design a multi-tenant FCC deployment with isolated persona catalogs and governance.
  3. Adapt FCC for industry verticals (healthcare, finance, government).
  4. Plan a migration path for upgrading to the v1.0.1 stable API.
  5. Evaluate the trade-offs between centralized and federated enterprise deployments.

The figure below shows a multi-tenant FCC deployment with shared simulation, event bus, and protocol infrastructure at the bottom, and three tenants on top — each with its own personas, constitution, and namespace.

flowchart TB
    subgraph SHARED["Shared Infrastructure"]
        SIM[Simulation Engine]
        EB[Event Bus]
        PROTO[Protocol Endpoints]
    end
    subgraph T1["Tenant A (Healthcare)"]
        P1[Custom Personas]
        G1[HIPAA Constitution]
        KG1[Namespace: tenant-a]
    end
    subgraph T2["Tenant B (Finance)"]
        P2[Custom Personas]
        G2[SOX Constitution]
        KG2[Namespace: tenant-b]
    end
    subgraph T3["Tenant C (General)"]
        P3[Custom Personas]
        G3[Standard Constitution]
        KG3[Namespace: tenant-c]
    end

    T1 --> SHARED
    T2 --> SHARED
    T3 --> SHARED
    SHARED --> CORE[(Core Persona Catalog<br/>102 Shared Personas)]

    style SHARED fill:#e3f2fd
    style T1 fill:#e8f5e9
    style T2 fill:#fff3e0
    style T3 fill:#f3e5f5

The core persona catalog is read-only and shared, which means upgrades to the framework flow through to every tenant automatically, while each tenant retains full authority over its bespoke personas and governance overlay.

From Team Tool to Enterprise Platform

Books 1 and 2 covered FCC as a tool for individual teams: install the package, define your personas, run your workflows. This is sufficient for many use cases, but enterprises have requirements that go beyond what a single-team deployment can satisfy:

  • Multi-tenancy. Multiple teams, each with their own personas and governance rules, sharing a single FCC infrastructure.
  • Compliance. Industry-specific regulations (HIPAA, SOX, GDPR, FedRAMP) that require auditable workflows and data handling.
  • Scale. Hundreds of concurrent simulations, thousands of artifacts, and millions of events.
  • Integration. Connection to existing enterprise systems (identity management, artifact repositories, CI/CD platforms, monitoring stacks).
  • Stability. A stable API that does not break when the framework is upgraded.

This chapter addresses each of these requirements and maps them to the FCC roadmap.

Multi-Tenant Architecture

A multi-tenant FCC deployment serves multiple teams from a shared infrastructure. Each team (tenant) has:

  • Its own persona catalog. Teams can define custom personas that are invisible to other teams, while still sharing the core catalog.
  • Its own governance rules. Each team's constitutions and quality gates are independent.
  • Its own knowledge graph namespace. Artifacts from different teams do not collide.
  • Shared infrastructure. The simulation engine, event bus, and protocol endpoints are shared.

Tenant Isolation

Isolation is implemented at three levels:

Level 1: Configuration Isolation

Each tenant has its own fcc.yaml with tenant-specific settings:

tenant:
  id: team_alpha
  name: "Team Alpha"
  namespace: "https://team-alpha.example.org/fcc/"

personas:
  sources:
    - "tenants/team_alpha/personas/"
  include_core: true

governance:
  constitutions: "tenants/team_alpha/constitutions/"
  quality_gates: "tenants/team_alpha/gates/"

Level 2: Runtime Isolation

The simulation engine maintains separate execution contexts per tenant. A tenant's simulations cannot access another tenant's artifacts, sessions, or events:

from fcc.enterprise.tenancy import TenantContext

with TenantContext("team_alpha"):
    # All operations within this block are scoped to team_alpha
    engine.run(scenario)
    # Artifacts, events, and traces are tagged with team_alpha

Level 3: Data Isolation

Each tenant's knowledge graph uses its own namespace (Chapter 4), ensuring that federated queries respect tenant boundaries. A cross-tenant query requires explicit authorization.

Shared Services

Some services are shared across tenants for efficiency:

  • Embedding provider. A single embedding model serves all tenants (the vectors are stored separately per tenant).
  • Event bus. A single bus with tenant-scoped topics.
  • Protocol endpoints. A single A2A/MCP server with tenant-aware routing.

Industry Verticals

Enterprise FCC deployments often serve specific industries with distinct requirements:

Healthcare

  • Persona catalog: Add HIPAA Compliance Officer, Clinical Data Steward, Medical Terminology Expert.
  • Governance: Hard-stop rules for PHI (Protected Health Information) handling. AOME integration for automatic PHI detection.
  • Quality gates: Clinical accuracy review, terminology validation against SNOMED/ICD-10.
  • Audit: Complete provenance chain for every clinical recommendation, exportable for regulatory review.

Financial Services

  • Persona catalog: Add SOX Compliance Auditor, Financial Data Analyst, Risk Modeler.
  • Governance: Hard-stop rules for material non-public information (MNPI). Segregation of duties between data access and decision-making personas.
  • Quality gates: Model validation, backtesting requirements, regulatory reporting format compliance.
  • Audit: Immutable audit trail with timestamping, compatible with SEC record-keeping requirements.

Government

  • Persona catalog: Add FedRAMP Assessor, Clearance-Aware Analyst, Policy Compliance Officer.
  • Governance: Hard-stop rules based on data classification levels (Unclassified, CUI, Secret). AOME integration for automatic classification.
  • Quality gates: Authority to Operate (ATO) compliance, NIST 800-53 control verification.
  • Deployment: On-premises or government cloud (GovCloud), no data egress to commercial environments.

Customizing for Your Vertical

The FCC plugin system makes vertical customization straightforward:

  1. Create a vertical plugin package (e.g., fcc-healthcare, fcc-finserv, fcc-gov).
  2. Contribute domain-specific personas via the persona plugin type.
  3. Contribute domain-specific governance rules via the governance plugin type.
  4. Contribute domain-specific quality gates via the scorer and validator plugin types.
  5. Contribute domain-specific scenarios via the scenario plugin type.

Install the vertical package alongside FCC, and the domain-specific capabilities are automatically discovered and registered.

Scale Considerations

Simulation Throughput

A single FCC process handles simulation sequentially within a session but can run multiple sessions concurrently. For high-throughput deployments:

  • Horizontal scaling. Run multiple FCC processes behind a load balancer, with shared state in a database.
  • Queue-based execution. Use a message queue (Redis, RabbitMQ, SQS) to distribute simulation tasks across workers.
  • Async execution. The async_adapter module provides async wrappers for the simulation engine, enabling non-blocking execution in async web frameworks.

Artifact Storage

The default file-based storage (JSON files) works for small deployments. At enterprise scale:

  • Database backend. Store artifacts, sessions, and traces in PostgreSQL or MongoDB.
  • Object storage. Store large artifacts (generated documents, code files) in S3 or Azure Blob.
  • Search index. Use Elasticsearch or a managed vector database for semantic search at scale.

Event Bus Scale

The in-process event bus handles thousands of events per second. For distributed deployments:

  • Redis Pub/Sub. Drop-in replacement for the in-process bus with network distribution.
  • Kafka. For high-volume, durable event streaming with replay capability.
  • CloudEvents. Standardized event format for cloud-native deployments.

The Road to v1.0.0

The FCC roadmap reached v1.0.1 (stable API) through three phases:

Phase 13 (v0.8.0): Knowledge Federation

Added semantic search, knowledge graphs, RAG pipelines, and federated knowledge -- the capabilities covered in this book's Chapters 1--4.

Phase 14 (v0.9.0): Evaluation and Compliance

Added automated evaluation frameworks, compliance reporting, and benchmarking:

  • Evaluation harness. Automated comparison of simulation outputs across models, configurations, and persona variations.
  • Compliance dashboard. Real-time visibility into governance posture across tenants.
  • Benchmark suite. Standardized scenarios for measuring FCC performance and quality.

Phase 15 (v1.0.0--v1.0.1): Platform Maturation

Stabilized the API and added enterprise-ready capabilities:

  • Stable API contract. Semantic versioning with guaranteed backward compatibility.
  • Multi-tenant infrastructure. First-class tenant isolation, configuration, and monitoring.
  • Domain verticals. Healthcare, finance, and legal vertical personas.
  • Enterprise support. Documentation, training materials, and support channels for enterprise adopters.

Migration Planning

If you are building on FCC, ensure you are on the latest v1.0.x by:

  1. Using the public API surface. Avoid depending on private modules (anything prefixed with _).
  2. Pinning your dependency. Use fcc>=1.0.0,<2.0.0 in your requirements for stable API compatibility.
  3. Writing tests against behavior, not implementation. Tests that verify persona outputs, workflow traversal, and governance results will survive API refactoring.
  4. Following the changelog. Each release includes a migration guide for any breaking changes.

Centralized vs. Federated Deployment

Two architectural patterns for enterprise FCC deployment:

Centralized

A single FCC instance serves all teams. All personas, workflows, and governance are managed centrally.

Pros: Consistent governance, easier management, single source of truth. Cons: Bottleneck risk, less team autonomy, change management overhead.

Best for: Regulated industries with strict governance requirements.

Federated

Each team runs its own FCC instance. A coordination layer (CONSTEL) enables cross-team discovery and knowledge sharing.

Pros: Team autonomy, independent scaling, blast radius containment. Cons: Governance inconsistency, duplication of effort, federation complexity.

Best for: Large enterprises with autonomous business units.

Hybrid

Central governance with federated execution. The governance team manages shared constitutions and quality gates; individual teams manage their own personas and workflows.

Pros: Balances governance consistency with team autonomy. Cons: Requires clear boundaries between shared and team-specific configuration.

Best for: Most enterprises. This is the recommended pattern.

Key Takeaways

  • Multi-tenancy requires isolation at configuration, runtime, and data levels.
  • Industry verticals are supported through domain-specific plugin packages.
  • Enterprise scale requires horizontal scaling, database backends, and distributed event buses.
  • The v1.0.0 roadmap adds evaluation, compliance, and platform maturation.
  • Hybrid deployment (central governance, federated execution) is the recommended enterprise pattern.
  • Build on the public API surface and pin your dependency version to ensure smooth migration.

Cross-References

← Chapter 7: Docs from Code | Back to Book 3 Index | Back to Series Index