Skip to content

FCC Quality Gates Reference

The quality-gates registry is the list of explicit, machine-checkable controls that FCC enforces against itself and downstream deployments. From v1.3.8, two registries coexist:

  • Core registry (30 gates) — src/fcc/data/governance/quality_gates.yaml
  • Extended registry (58 gates) — src/fcc/data/governance/quality_gates_extended.yaml, vendored from PHOENIX v4.0.0

The extended registry extends (never replaces) the core registry. Together they cover framework completeness, plugin conformance, and multi-jurisdictional compliance.

Tier Structure

Every gate carries one of three tier labels:

Tier Meaning Audit Disposition
tier_1 Core framework completeness Blocks release
tier_2 Compliance & risk Must be remediated for high-risk deployments
tier_3 Orchestration & federation Improvement item; tracked but not blocking

tier_1 maps to your "Must Fix" bucket. tier_2 maps to "Should Fix." tier_3 maps to "Nice to Have."

The Three Categories

The extended registry organises its 58 gates into three categories matching the PHOENIX v4.0.0 scorecard:

flowchart LR
    Reg[Extended Registry<br/>58 gates] --> Core[Core Framework<br/>28 gates]
    Reg --> Plugin[Plugins<br/>15 gates]
    Reg --> Comp[Compliance<br/>15 gates]

    Core --> P[Personas]
    Core --> X[Cross-cutting]

    Plugin --> AOME[AOME scope]
    Plugin --> CONSTEL[CONSTEL scope]
    Plugin --> PAOM[PAOM scope]

    Comp --> EU[EU AI Act]
    Comp --> NIST[NIST AI RMF]
    Comp --> Other[GDPR, CCPA, HIPAA, + 6]

    classDef reg fill:#e3f2fd,stroke:#0d47a1;
    classDef cat fill:#c8e6c9,stroke:#2e7d32;
    classDef leaf fill:#fff9c4,stroke:#f57f17;
    class Reg reg;
    class Core,Plugin,Comp cat;
    class P,X,AOME,CONSTEL,PAOM,EU,NIST,Other leaf;

Category 1 — Core Framework (28 gates)

Framework-wide gates owned by specific FCC personas or cross-cutting checks. The scorecard:

Status Count
Covered 8
Partial 12
Gap 8

Representative gates (IDs are stable across releases):

ID Owner Tier What it checks
QG-RC-001 Research Crafter tier_1 Research inventory completeness
QG-BC-001 Blueprint Crafter tier_1 Blueprint artefact completeness
QG-AMS-001 Agent Metric Scorer tier_1 Hallucination check stub (closed in v1.3.8)
QG-GCA-001 Governance Compliance Auditor tier_1 Wired into fcc audit (closed in v1.3.8)
QG-DGS-001 Documentation Strategist tier_2 Data-flow frontmatter exemplar (closed in v1.3.8)

Three tier-1 gaps closed in v1.3.8:

  • QG-GCA-001 — the governance auditor is now invoked by default when fcc audit runs
  • QG-DGS-001 — the Forensic Auditor persona YAML now carries a data_flow frontmatter exemplar
  • QG-AMS-001 — a check_hallucinations() stub lives at fcc.scoring.hallucinations

Category 2 — Plugins (15 gates)

Gates scoped to specific ecosystem plugins. Status: 0 covered, 4 partial, 11 gap at the extended-registry launch. The gaps are deliberate — each is a contract that downstream plugin authors must satisfy.

Representative:

ID Plugin Scope Tier Check
QG-AOME-001 AOME tier_2 Vocabulary mapping completeness
QG-CONSTEL-001 CONSTEL tier_2 Business process coverage
QG-PAOM-001 PAOM tier_2 Object model conformance

Plugin-scoped gates are advisory for deployments that do not use the plugin. Auditors should scope these gates to the plugins actually installed in the audited deployment.

Category 3 — Compliance (15 gates)

Gates mapping to regulation articles. Status: 0 covered, 2 partial, 13 gap. The "gap" status here reflects the regulatory-evidence-collection work that operators must do; the gate itself is shipped.

Regulation Representative Gate Maps to
EU AI Act QG-EUAIA-001 Article 9 Risk Management System
NIST AI RMF QG-NIST-001 GV-1 Organisational Policies
GDPR QG-GDPR-001 Article 5 Principles
CCPA QG-CCPA-001 Section 1798.100
HIPAA QG-HIPAA-001 45 CFR 164.308

Six additional jurisdictions are covered in the remaining 10 gates; see the YAML for the exhaustive list.

Running the Gates

# Run all gates (extended + core)
fcc audit --strict --gates all

# Run gates for one category only
fcc audit --strict --gates-category compliance

# Run gates for a specific tier
fcc audit --strict --gates-tier tier_1

# Export a scorecard
fcc audit --gates-scorecard /tmp/scorecard.json

The scorecard JSON is the right format to attach to an audit engagement. It contains:

  • Per-gate status (pass, partial, fail, skip)
  • Per-gate evidence (the specific artefact that satisfied or failed the gate)
  • Summary by tier and category
  • Diff against the previous audit (if --baseline is provided)

Mapping to Common Control Frameworks

Auditors working against a standard control framework (ISO/IEC 27001, SOC 2, NIST 800-53) will want a mapping from FCC gates to their framework. The recommended approach:

  1. Export the full gate list: fcc audit --gates-list --format csv > gates.csv
  2. In a spreadsheet, add a column for each control-framework ID your engagement cares about
  3. Fill it in row-by-row (a one-off exercise of a few hours for a complete registry)
  4. Save the mapping under version control; it becomes an auditor artefact

Pre-built mappings for EU AI Act and NIST AI RMF ship in the registry. Other frameworks are community-contributed via plugins.

Interpreting partial Status

A partial gate is one where FCC has some of the required controls but not all. The registry surfaces this honestly rather than overclaiming. When you see partial, the remediation field tells you exactly what is missing.

Example:

- id: QG-BC-001
  fcc_status: partial
  remediation: "Raise blueprint artefact completeness to include formal ADRs for every major design choice."

An audit finding for partial is appropriate when the missing portion materially affects the compliance claim. For low-risk deployments, a partial may be acceptable with compensating controls.

Gate Evolution

Gates are versioned. When a gate's definition changes, its ID stays stable but its version field bumps. This means:

  • Historical audits remain valid (reproducible against the gate version in effect at the time)
  • New gates are added via minor releases; existing gates are rarely removed
  • A gate that is deprecated is marked deprecated: true but remains in the registry for at least two release cycles

Track the gate version in your engagement record alongside the FCC version and git rev.

Persona-to-Gate Matrix

For auditors who prefer a persona-first lens:

fcc audit --gates-by-persona --format json > /tmp/persona_gates.json

The output groups gates by persona_id so you can evaluate each persona's governance surface in one pass. Pair this with the R.I.S.C.E.A.R. Completeness check for a complete per-persona audit.

Gate Development Lifecycle

When FCC or a plugin adds a new gate:

  1. Gate is authored in YAML with provisional fcc_status: gap
  2. CI verifies the gate is syntactically valid
  3. Gate is implemented (code written, tests added)
  4. Gate graduates to partial or covered
  5. Release notes document the new gate
  6. Auditors update their mapping spreadsheet on next engagement

The governance module docs document the gate-development process in full.