FCC for Architects¶
Welcome to the FCC architect track. This section is written for enterprise and software architects evaluating FCC as a candidate for their organisation's agent-team infrastructure. The three questions that typically drive that evaluation are:
- Does FCC's system context match our environment? Which upstream authorities, direct consumers, and partner libraries does FCC already talk to, and how does that map to our own landscape?
- Which FCC tier are we adopting? Strict (Tier 1, CI-breaking), Active (Tier 2, version-pinned), or Minimal (Tier 3, optional runtime)?
- Which architectural risks are we taking on, and how are they mitigated? Governance gates, compliance pipelines, and the quality-gate surface are FCC's primary answers.
This landing page is the entry point to the four supporting documents that answer those questions in detail.
Architect reading list¶
- System Context — the C4 Level 1 diagram and the 19-project ecosystem summary.
- Decision Checklist — twelve questions every architect should answer before approving FCC adoption.
- 4+1 Reference — pointer doc to the 4+1 UML views and which view to use for which architectural task.
- Risk and Mitigation — common integration risks and FCC's built-in mitigations.
Why an architect track¶
The existing documentation splits cleanly between teaching (beginners, educators, scientists) and building (developers, professionals). Architects sit at a different altitude: they need structural maps rather than code samples, decision frameworks rather than tutorials, and risk models rather than quick starts. This track is built for that altitude.
Every page here assumes you are comfortable reading UML class diagrams, C4 context diagrams, and data-flow diagrams. If the term "4+1 view" is unfamiliar, start with 4+1 Reference — it is the shortest path to the architectural vocabulary FCC uses.
The FCC ecosystem in one paragraph¶
FCC is the authoritative project for the Find-Create-Critique framework and the R.I.S.C.E.A.R. persona specification. It ships as a Python package with 147 personas across 20 core categories and 6 vertical packs, an 11-type plugin surface, six integration protocols (Python SDK, CLI, MCP, A2A, WebSocket bridge, vendored YAML), and a governance layer covering 58 quality gates, 256+ EU AI Act requirements, and 29 NIST AI RMF subcategories. Nineteen ecosystem projects depend on FCC across three trust tiers; see System Context for the full tier map.
Where FCC fits in your enterprise architecture¶
FCC is not a platform, a runtime, or a product. It is a framework — a structured set of abstractions, data, and tooling that an application integrates with to get agent-team capabilities. The typical enterprise integration sits above your existing LLM provider, alongside your existing observability stack, and beneath your application-specific workflow logic. The Risk and Mitigation page covers the four most common architectural concerns with that positioning and what FCC offers as answers.
Related FCC documentation¶
- Architecture — Context Diagram — the canonical Level 1 C4 diagram this track references.
- Architecture — Logical View — the persona, plugin, and compliance class models.
- Architecture — Physical View — deployment topology (Docker, Helm, kind).
- Ecosystem Alignment Status — the live 19-project status dashboard.
- For Professionals — the enterprise deployment and compliance track for architects who are also the implementers.
- Decision Records — ADRs for every major architectural choice.
v1.4.x What's New for Architects¶
Every v1.4.x release touches your altitude. SAFe adoption (v1.4.1) introduces the three-ART / four-value-stream model. The dual-bus event split (v1.4.2) changes the physical deployment topology. Patent and industry-paper delegation (v1.4.3) formalises the three-authority model — FCC, NEXUS, PHOENIX. Zachman coevolution (v1.4.1) absorbs a 6×6 cross-cut that every OTel span now carries. If you approve FCC adoption decisions, these five chapters are mandatory reading.
- Guidebook Ch. 31 — SAFe Adoption in FCC — portfolio-level adoption mechanics.
- Guidebook Ch. 32 — Dual-Bus Event Model — deployment topology and OTel tracer strategy.
- Guidebook Ch. 33 — Patent Delegation to PHOENIX — ecosystem IP authority choice.
- Guidebook Ch. 34 — Industry Paper Handoff to NEXUS — publication authority choice.
- Guidebook Ch. 35 — Zachman Coevolution — pattern-absorption mechanics with JV partners.
- Sample Prompts — Architect v1.4.x Decision Walk
- Sample Prompts — Patent Delegation Walkthrough
- docs/safe/README.md — authoritative SAFe operating-model doc for every architectural discussion.
- docs/ecosystem/alignment-status.md — 19-project alignment dashboard.
- Notebook
40_dual_bus_event_model.ipynb,41_patent_delegation.ipynb,43_zachman_cross_cut.ipynb— the three architecturally-loaded v1.4.x notebooks.
See also — other audience tracks¶
- Developers building on FCC? → For Developers
- Decision-makers evaluating ROI? → For Decision Makers
- Enterprise deployment teams? → For Professionals
- Teaching or training? → For Educators