Skip to content

Adoption Decision Checklist

The twelve questions below are the minimum set an architect should be able to answer before approving FCC adoption. They are grouped into four themes: tier, integration shape, compliance scope, and agile / operational layer. For each question the checklist names the artifact that helps you answer it, so this page doubles as a reading list.

Theme 1 — Tier

1. Which FCC trust tier are we adopting?

Strict (Tier 1), Active (Tier 2), or Minimal (Tier 3). The answer drives your CI gating, your release cadence commitment, and the headcount you need for keeping the integration healthy.

See System Context for the tier definitions and the six current Tier 2 projects as reference points.

2. Who in our organisation owns the pin?

A pinned FCC version is only as good as the person who bumps it. If no one owns the pin, Tier 1 is not available to you — downgrade to Tier 2 or Tier 3.

See docs/ecosystem/alignment-status.md for how the existing consumers allocate ownership.

3. How often will we accept breaking changes?

FCC's 4-part PEP 440 scheme signals breaking changes at MAJOR and structural changes at MINOR. The v1.3.5.x hotfix run was four patches in five days; the v1.4.0 ecosystem pivot is the next MAJOR-adjacent event. Match your tolerance to FCC's cadence.

Theme 2 — Integration shape

4. Which of the eight integration surfaces will we use?

The full list is in System Context. The minimum viable set for a new Tier 2 integration is the Python SDK plus one protocol (either MCP or A2A). Vendored YAML is inbound-only and automatic.

5. Which plugin types will we ship?

FCC has 11 plugin types. For cross-project entity resolution you want VocabularyProviderPlugin. For custom scoring you want ScorerPlugin. For reacting to runtime events you want EventSubscriberPlugin. See the Plugin Taxonomy in the Logical View for the full tree and For Developers — Plugin Development for authoring steps.

6. Do we need the 4+1 Physical View (Docker, Helm, kind)?

Tier 1 and Tier 2 consumers typically do; Tier 3 consumers rarely do. The full deployment topology is in Architecture — Physical View.

Theme 3 — Compliance scope

7. Which regulatory regime are we subject to?

FCC ships a compliance pipeline covering 256+ EU AI Act requirements (Regulation 2024/1689) and 29 NIST AI RMF subcategories with a bidirectional crosswalk. If your regime is neither, the pipeline still gives you a substrate to bolt a new regulation onto without changing auditor code.

See For Professionals — Governance and Compliance for the compliance surface in detail.

8. What is our risk appetite for high-risk AI Act classifications?

FCC's AIActClassifier assigns every persona a risk category; some of the 147 personas classify as high-risk by default. The classification is transparent and overrideable, but you must decide on the operational response before enabling the compliance pipeline.

9. Do we need evidence graphs?

build_compliance_evidence_graph() produces a JSON-LD evidence graph linking requirements to personas to artifacts. It is the defensible-paper-trail artifact for audit. If your regime has documentation obligations, the answer is yes.

Theme 4 — Agile / operational layer

10. Which scaled-agile layer will consume FCC?

FCC is framework-level tooling. It layers cleanly under Scrum at the team level, under SAFe ARTs at the program level, and under LPM at the portfolio level. The fit that matters is between FCC's persona catalog and your team topology. See the Ecosystem Overview in Book 1 for how the existing consumers organise around personas.

11. What is our observability contract with FCC?

FCC emits 81 event types on an in-process thread-safe bus, plus OpenTelemetry-compatible traces and metrics. The operational contract is: you subscribe to the events your team cares about, and FCC guarantees their structural stability across MINOR releases. See For Professionals — Integration Guide for the wiring.

12. What is our on-call handoff for FCC incidents?

FCC is a library, not a service. Incidents are either "our-code-misuses-FCC" (owned by us) or "FCC-bug" (owned by the FCC maintainers). The distinction is almost always clear from the stack trace. On-call training for a new FCC adoption should cover the eight integration surfaces and the eleven plugin types so the on-call engineer can localise any incident to the correct side of the boundary.

Deliverable

Fill in a one-page RFC-style document that answers all twelve questions. The FCC team will happily review it before your adoption starts — open an issue referencing this checklist and drop the RFC in the body.