Skip to content

Getting Started (Policy Makers)

This page is a zero-prerequisite orientation. You will not write code. By the end you will have a shared vocabulary with the technical team, a mental model of what an FCC system does, and a checklist for your first policy-relevant conversation.

The one-minute summary

FCC stands for Find, Create, Critique. It is a framework for building AI systems that behave like multi-disciplinary human teams: a "Finder" agent surfaces relevant context, a "Creator" agent drafts output, and a "Critique" agent scrutinizes the draft against a specification. Each agent role is defined by a persona — a YAML document with ten structured fields (the R.I.S.C.E.A.R. spec). Personas carry explicit constraints, responsibilities, and risk tags, which is what lets a policy reviewer audit the system at all.

A deployment might include 5 personas or 164. The current canonical catalog ships 164 personas across 20+ categories (core, integration, governance, stakeholder, champion, ML lifecycle, data engineering, DevOps, UX, and six full vertical packs).

Why the three-step cycle matters for policy

Single-agent AI systems (one prompt, one LLM, one answer) are hard to audit because all the reasoning happens inside an opaque model call. The Find → Create → Critique cycle externalizes the reasoning into at least three inspectable steps, each with its own persona, constraints, and logged output. From a policy standpoint, this is closer to the separation-of-duties pattern familiar from financial controls: the person drafting is not the same person checking.

Key objects you will encounter

  • Persona (YAML file) — defines a role. Example categories: ml_lifecycle, governance, healthcare, finance. The YAML includes a risk_category field (minimal / limited / high / unacceptable) that drives compliance routing.
  • Scenario — a JSON file describing a single FCC run: which personas participate, what the input is, which workflow graph executes.
  • Workflow graph — a directed acyclic graph of steps. FCC ships seven canonical graphs ranging from 5 to 84 nodes.
  • Compliance report — a JSON artifact emitted after an audit. Contains findings, evidence, remediation status.
  • Model card — a Markdown document (one per persona) with responsibilities, constraints, known limitations, intended use.

A small example

Imagine a municipal government uses FCC-based Crater (the legal-vocabulary constellation-vertical) to triage citizen requests for public records. The deployment runs three personas:

  • A Finder tagged risk_category: limited that retrieves the relevant statute and precedent.
  • A Creator tagged risk_category: limited that drafts a response.
  • A Critique tagged risk_category: high that checks the draft against redaction rules and citizen-privacy constraints.

The deployment's overall risk posture is high (the maximum of its parts). The compliance report must therefore include every Article 9-15 requirement from the EU AI Act. The model cards for the three personas are delivered to the municipal legal counsel before go-live.

Even if you never read the source code, you can understand the deployment at this level of description — and that is enough to draft a procurement clause, an oversight resolution, or a constituent-facing FAQ.

What you can ask the technical team

Here is a ready-made checklist of questions that produce policy-useful answers:

  1. "What is the highest risk_category among the personas in this deployment?"
  2. "Can I see the compliance report from the last audit? (JSON is fine.)"
  3. "Which persona in this deployment has the responsibilities field that mentions the decision I'm worried about?"
  4. "Which EU AI Act articles are flagged as non-compliant or partial?"
  5. "Is there a NIST AI RMF crosswalk? (There should be — 29 subcategories are mapped.)"
  6. "What vertical pack does this deployment inherit from?" (Answers: healthcare, finance, legal, insurance, energy, government — or none.)

What you should not worry about (yet)

  • Model weights. Policy usually does not need to touch them; the model card describes them.
  • Python package internals. The src/fcc/ tree is engineering-owned.
  • Plugin code. Plugins produce evidence you can read without caring how they were built.

Where next

Proceed to Audit Primer to learn how to read a compliance report end-to-end. If you want the shortest possible path to producing a brief, skip to Policy Brief Generation. Definitions live in Ecosystem Glossary.