Skip to content

Chapter 24: Building on FCC

This final guidebook chapter provides guidance for teams building production systems on top of the FCC framework. It covers architecture decisions, extension patterns, vertical adaptations, and the path from prototype to production.

The timeline below sketches a twelve-week path from first-install exploration through customization and integration to production deployment.

timeline
    title From Prototype to Production
    section Phase 1 - Exploration
        Weeks 1-2 : Install FCC, run mock scenarios
                  : Browse persona catalog
                  : Complete Jupyter notebooks
    section Phase 2 - Customization
        Weeks 3-4 : Define custom personas
                  : Create custom workflows
                  : Establish baselines
    section Phase 3 - Integration
        Weeks 5-8 : Connect LLM provider
                  : CI/CD pipeline integration
                  : Compliance auditing setup
    section Phase 4 - Production
        Weeks 9-12 : Migrate to React frontend
                   : Event bus monitoring
                   : KG federation
                   : Maturity assessment

Teams with tighter constraints can compress the schedule, but skipping the customization phase is a common source of later rework.

Architecture Decision Framework

When building on FCC, key architectural decisions include:

Decision Options Recommendation
Deployment model Embedded library / Standalone service Start embedded, extract services as scale demands
Data persistence File-based / Database-backed File-based for development; database for production
LLM provider Anthropic / OpenAI / Local Anthropic for quality; local for privacy-sensitive domains
UI technology Streamlit / React / Custom Streamlit for prototyping; React for production
Federation scope Single-project / Multi-project Single-project first; federate when cross-project queries are needed

Extension Patterns

Custom Persona Plugins

Add domain-specific personas without modifying the core catalog:

# my_personas/healthcare.yaml
personas:
  - id: clinical_researcher
    name: Clinical Researcher
    fcc_phase: Find
    category: healthcare
    riscear:
      role: "Conducts clinical literature reviews..."
      # ... full R.I.S.C.E.A.R. spec

Register the plugin:

from fcc.personas.registry import PersonaRegistry

registry = PersonaRegistry.from_package_data()
custom = PersonaRegistry.from_yaml("my_personas/healthcare.yaml")
merged = registry.merge(custom)

Custom Workflow Plugins

Design workflows for domain-specific processes:

  1. Define workflow graph nodes and edges in JSON.
  2. Register actions for each node.
  3. Attach approval gates at decision points.
  4. Test with mock simulation.

Custom Scorer Plugins

Implement domain-specific scoring rubrics:

from fcc.collaboration.scoring import ScoringEngine

class ClinicalScoringEngine(ScoringEngine):
    def score_deliverable(self, deliverable_id, scorer, score, **kwargs):
        # Add clinical-specific validation
        if kwargs.get("requires_peer_review") and not kwargs.get("peer_reviewed"):
            score = min(score, 2.0)  # Cap score if peer review missing
        return super().score_deliverable(deliverable_id, scorer, score, **kwargs)

Custom Event Subscribers

React to framework events with domain-specific logic:

from fcc.messaging.bus import EventBus
from fcc.messaging.events import Event, EventType

bus = EventBus()

def compliance_alerter(event: Event) -> None:
    if event.data.get("risk_category") == "HIGH":
        send_alert(event.data)

bus.subscribe(EventType.COMPLIANCE_CHECK_COMPLETED, compliance_alerter)

Vertical Adaptations

Healthcare

  • Personas: Clinical researcher, medical reviewer, HIPAA compliance officer.
  • Workflows: Literature review, clinical trial protocol, adverse event reporting.
  • Compliance: HIPAA overlay on EU AI Act requirements.
  • Quality gates: Peer review mandatory at all Create-phase gates.

Financial Services

  • Personas: Risk analyst, regulatory reporter, fraud investigator.
  • Workflows: Risk assessment, regulatory filing, anomaly detection.
  • Compliance: SOX, Basel III overlays.
  • Quality gates: Four-eyes principle enforced at approval gates.

Government

  • Personas: Policy analyst, procurement officer, transparency auditor.
  • Workflows: Policy review, procurement evaluation, FOIA response.
  • Compliance: FedRAMP, NIST SP 800-53 overlays.
  • Quality gates: Classification review at all output gates.

Education

  • Personas: Curriculum designer, learning assessor, accessibility reviewer.
  • Workflows: Course design, assessment creation, accessibility audit.
  • Compliance: FERPA, WCAG overlays.
  • Quality gates: Pedagogical review at curriculum design gates.

From Prototype to Production

Phase 1: Exploration (Weeks 1-2)

  1. Install FCC and run sample scenarios in mock mode.
  2. Browse the persona catalog; identify personas relevant to your domain.
  3. Run the Streamlit dashboards to understand available visualizations.
  4. Complete 3-5 Jupyter notebooks.

Phase 2: Customization (Weeks 3-4)

  1. Define 5-10 custom personas for your domain.
  2. Create 2-3 custom workflows.
  3. Implement domain-specific scoring rubrics.
  4. Run benchmarks to establish baselines.

Phase 3: Integration (Weeks 5-8)

  1. Connect to your LLM provider in AI mode.
  2. Integrate with your CI/CD pipeline.
  3. Set up compliance auditing for your regulatory context.
  4. Deploy Streamlit dashboards for stakeholders.

Phase 4: Production (Weeks 9-12)

  1. Migrate from Streamlit to React if needed.
  2. Implement event bus integration with your monitoring stack.
  3. Set up knowledge graph federation with other data sources.
  4. Conduct maturity assessment and plan improvements.

Monitoring and Operations

Key Metrics to Track

Metric Source Alert Threshold
Simulation success rate Observability metrics < 95%
Average CLEAR+ efficacy Benchmark results < 0.7
Compliance rate Compliance auditor < 90%
Session completion rate Collaboration engine < 80%
API cost per simulation Token tracking > $5.00

Operational Runbook

  1. Simulation failure: Check event bus for error events; inspect trace for the failing step; verify persona constitution compliance.
  2. Compliance degradation: Run full audit; review recent persona or constitution changes; check for requirement updates.
  3. Cost spike: Review token usage metrics; check for runaway simulations; verify budget guardrails.

Contributing Back

If you build reusable extensions, consider contributing them:

  1. Personas: Submit domain-specific persona YAML files.
  2. Workflows: Share workflow graph definitions for common patterns.
  3. Plugins: Package custom plugins with tests and documentation.
  4. Compliance overlays: Contribute regulatory mappings for additional frameworks.

Lab Exercise

Lab 24.1: Define 3 custom personas for a domain of your choice. Validate them against the persona schema and run a mock simulation.

Lab 24.2: Create a production readiness checklist for an FCC deployment. Include items for security, compliance, monitoring, and documentation.

Lab 24.3: Conduct a maturity assessment using MaturityAssessor. Identify your team's biggest gap and draft a 4-week improvement plan.

Summary

  • FCC supports multiple extension patterns: custom personas, workflows, scorers, and event subscribers.
  • Vertical adaptations for healthcare, finance, government, and education demonstrate the framework's flexibility.
  • The prototype-to-production path spans 12 weeks across exploration, customization, integration, and production phases.
  • Monitoring key metrics (simulation success, CLEAR+ scores, compliance rate, session completion, API cost) ensures operational health.
  • Contributing reusable extensions back to the ecosystem benefits all FCC adopters.