Chapter 30: The Auditor Compliance Walkthrough¶

New in v1.3.10. This final chapter of the v1.3.x series walks an auditor — internal, external, or regulatory — from zero to a completed compliance audit on an FCC deployment. It assumes no prior FCC knowledge and treats the auditor as a first-class persona with their own navigation path.

Why an auditor chapter¶

FCC's compliance story is visible to the auditor in six artifacts:

The quality-gate registry (src/fcc/data/governance/quality_gates.yaml)
The constitution registry (per-persona, tiered)
The EU AI Act requirement set (src/fcc/data/compliance/eu_ai_act_requirements.yaml)
The NIST AI RMF mapping (src/fcc/data/compliance/nist_ai_rmf_mapping.yaml)
The model cards (173 files under docs/model-cards/)
The evidence graph (generated on audit)

This chapter walks the auditor through each in order, producing a compliance assessment the auditor can defend to their own reviewer.

Preparation¶

The auditor needs three things before starting:

A working FCC install (see Getting Started).
Read access to the adopter's custom personas, plugins, and scenarios.
A target regulation — EU AI Act, NIST AI RMF, GDPR, HIPAA, SOC 2, SOX, or the cross-regulation summary.

No production access needed

The audit uses artifacts, not live systems. The auditor does not need access to the production FCC instance — a git-clone and a local fcc binary is enough.

The audit flow¶

The diagram below shows the full audit flow end-to-end. It is a sequence diagram because the ordering matters — skipping steps produces findings that don't ground in the evidence chain.

sequenceDiagram
    participant A as Auditor
    participant CLI as fcc CLI
    participant REG as RequirementRegistry
    participant CL as AIActClassifier
    participant AU as ComplianceAuditor
    participant EG as Evidence Graph
    participant DB as Dashboard

    A->>CLI: fcc compliance list-regulations
    CLI-->>A: EU AI Act, NIST AI RMF, ...

    A->>CLI: fcc compliance load --regulation eu_ai_act
    CLI->>REG: load requirements
    REG-->>CLI: 256+ requirements

    A->>CLI: fcc compliance classify --persona all
    CLI->>CL: classify each persona
    CL-->>CLI: risk categories

    A->>CLI: fcc compliance audit --regulation eu_ai_act
    CLI->>AU: full audit
    AU-->>CLI: AuditReport
    CLI->>EG: build evidence graph
    EG-->>CLI: nodes + edges

    A->>DB: fcc dashboard compliance-audit
    DB-->>A: findings + risk heatmap

Step 1 — List and load the regulation¶

fcc compliance list-regulations
# => eu_ai_act, nist_ai_rmf, gdpr, hipaa, sox, soc2, cross_regulation

fcc compliance load --regulation eu_ai_act
# => Loaded 256 requirements from src/fcc/data/compliance/eu_ai_act_requirements.yaml

The EU AI Act set ships with 256+ requirements mapped to Regulation 2024/1689 articles. The NIST AI RMF set ships with 29 subcategories with bidirectional crosswalk to the EU AI Act. Every other regulation ships with a published crosswalk.

Step 2 — Risk-classify the persona roster¶

FCC classifies every persona into one of the EU AI Act risk categories: minimal, limited, high, or unacceptable. The classifier at src/fcc/compliance/classifier.py uses the persona's domain, archetype, and data-flow profile to assign the category.

fcc compliance classify --persona all --out classification.csv

The CSV has one row per persona with columns:

Persona ID
Role title
Archetype
Risk category
Justification (first 80 chars)
Applicable requirement IDs (comma-separated)

What the auditor does with the classification¶

Spot-check 10 random rows. If the classifier's justification doesn't ring true, that's a finding.
Filter to high and unacceptable. These are the personas the EU AI Act requires the most evidence for.
Confirm coverage. Every persona in the adopter's registry should appear; gaps are a finding.

Step 3 — Run the full audit¶

fcc compliance audit --regulation eu_ai_act --out audit.json
fcc compliance audit --regulation eu_ai_act --out audit.md --format markdown

The ComplianceAuditor at src/fcc/compliance/auditor.py walks every requirement, checks the evidence, and produces an AuditReport. The report has:

Per-requirement pass/fail/partial status
Evidence pointers (file paths + line numbers)
Severity ranking (blocker / high / medium / low)
Remediation suggestions

The Markdown rendering is what the auditor reads. The JSON is what downstream tooling consumes (CI dashboards, GRC integrations, ticket creation).

Step 4 — Build and inspect the evidence graph¶

fcc compliance evidence-graph --regulation eu_ai_act --out evidence.json
fcc compliance evidence-graph --regulation eu_ai_act --out evidence.ttl --format turtle

The evidence graph is a directed graph with:

Requirement nodes — one per regulation article / subcategory
Persona nodes — one per persona in scope
Artifact nodes — model cards, traces, audit reports
Edge types — satisfies, documents, traces_to, signed_by

The Turtle export (RDF) is what external GRC systems ingest. The JSON is what the dashboard renders.

Step 5 — Review in the dashboard¶

fcc dashboard compliance-audit --report audit.json --graph evidence.json

The dashboard shows three panes:

Heatmap — persona × regulation grid, coloured by pass/fail
Findings — sorted by severity, browsable
Evidence — click-through from finding to source file

The auditor spends the most time here. Every "fail" in the heatmap gets clicked, the evidence trail followed back to the source artifact, and a finding written up.

The regulation-specific dashboards¶

FCC v1.3.x ships dashboards for 12 regulations under docs/governance/dashboards/. Each dashboard covers the relevant articles, cross-references the FCC personas and gates that satisfy them, and links to the model cards.

Regulation	Dashboard
GDPR	`docs/governance/dashboards/gdpr.md`
CCPA / CPRA	`docs/governance/dashboards/ccpa.md` / `cpra.md`
HIPAA	`docs/governance/dashboards/hipaa.md`
SOX	`docs/governance/dashboards/sox.md`
SOC 2	`docs/governance/dashboards/soc2.md`
ISO 27001	`docs/governance/dashboards/iso-27001.md`
PCI DSS	`docs/governance/dashboards/pci-dss.md`
FedRAMP	`docs/governance/dashboards/fedramp.md`
EU AI Act	`docs/governance/dashboards/ai-act.md`
DORA	`docs/governance/dashboards/dora.md`
NIS2	`docs/governance/dashboards/nis2.md`

Cross-regulation findings (a finding that applies in GDPR and HIPAA and SOC 2) are consolidated in the cross-regulation summary.

The severity model¶

Findings are graded on a four-point severity scale.

Severity	Meaning	SLA
Blocker	Regulation not satisfiable; release must be held	Fix before merge
High	Gap threatens compliance posture	Fix in current release
Medium	Risk present but not immediate	Fix in next release
Low	Best-practice improvement	Tracked as tech debt

Auditor reports carry severity inline with every finding. Operators use the severity to prioritise; architects use it to plan the evolution roadmap.

Evidence graph structure¶

The PlantUML diagram below shows the node and edge types in the evidence graph. An auditor tracing a finding back to its source walks the satisfies and documents edges in reverse from a requirement node to the artifact that supplied the evidence.

@startuml
skinparam monochrome true
skinparam shadowing false

class "Requirement" as R {
  + id: str
  + regulation: str
  + article: str
  + severity: Severity
}
class "Persona" as P {
  + persona_id: str
  + risk_category: RiskCategory
}
class "Artifact" as A {
  + kind: str
  + path: str
  + sha: str
}
class "Finding" as F {
  + id: str
  + severity: Severity
  + status: str
}

R "0..*" <-- "0..*" P : satisfies
P "0..*" <-- "0..*" A : documents
R "0..*" <-- "0..*" A : traces_to
A "0..*" <-- "0..*" F : signed_by
R "0..*" <-- "0..*" F : raises

note bottom of R
  One per EU AI Act article
  or NIST subcategory.
end note
note bottom of A
  Model cards, traces,
  audit reports.
end note
@enduml

Reading the graph in the dashboard¶

In fcc dashboard compliance-audit, the evidence graph is surfaced as a sidebar on every finding. Click a requirement ID to see:

The persona set that satisfies it
The artifacts that document the satisfaction
The findings that raise concerns
The SHA of each artifact (for audit integrity)

A well-formed audit trail has non-empty values in every column. Empty columns are either an operator gap (missing artifact), an architect gap (missing persona), or an engineer gap (missing documentation).

Finding-writing template¶

A well-formed finding has six fields. Use this template when writing a finding in Markdown.

### Finding <id>: <short title>

**Severity.** <blocker|high|medium|low>

**Regulation.** <regulation> — Article <id>

**Persona / artifact.** <persona id> (<file path>)

**Observation.** <what the auditor saw>

**Impact.** <what could go wrong>

**Remediation.** <what the adopter should do>

The audit maturity ladder¶

Just as developers climb a five-phase journey, auditors climb a three-rung maturity ladder.

flowchart LR
    R1[Rung 1<br/>Read the artifacts] --> R2[Rung 2<br/>Trace the evidence]
    R2 --> R3[Rung 3<br/>Run the pipeline]

    R1 -.->|tool| T1[Dashboard]
    R2 -.->|tool| T2[Evidence graph]
    R3 -.->|tool| T3[fcc compliance pipeline]

A worked finding¶

Here is a representative finding drawn from a synthetic audit. It demonstrates the template and the tone expected.

Finding EUAIACT-2025-001: Missing data_flow on Blueprint Crafter¶

Severity. High

Regulation. EU AI Act — Article 10 (Data governance)

Persona / artifact. BC — Blueprint Crafter (src/fcc/data/personas/core_personas.yaml)

Observation. The Blueprint Crafter persona does not carry a data_flow block. Article 10 requires that high-risk AI systems document the categories of personal data processed, the retention policy, and the data-quality assurances.

Impact. An Article 10 audit would not find defensible evidence that the Blueprint Crafter's inputs and outputs are classified, retained, or quality-assured to the regulation's standard.

Remediation. Add a data_flow block to the Blueprint Crafter persona following the Data Governance template. The Forensic Auditor persona is the current v1.3.8 exemplar and should be used as the pattern.

Sample-prompt cross-references¶

Knowledge check¶

(Short) How many EU AI Act requirements ship with FCC v1.3.x?
(Short) Which file contains the quality-gate registry?
(Short) At what severity must a finding be fixed before merge?
(Short) Which rung on the auditor maturity ladder requires running the pipeline locally?

Answers¶

256+.
src/fcc/data/governance/quality_gates.yaml.
Blocker.
Rung 3.