Skip to content

Compliance Audit Pipeline

This diagram traces how a single persona is audited against the 256+ EU AI Act requirements (plus the 29 NIST AI RMF crosswalk) and how findings, evidence, and a final report are produced. The entry point is ComplianceAuditor.audit_persona(spec) at src/fcc/compliance/auditor.py:48, orchestrated by compliance/pipeline.py for bulk runs. Developers read this trace to understand where risk categorisation happens, how constitution compliance is layered on top, and how the evidence graph is constructed from raw findings. The pipeline emits events that downstream subscribers (for example the reactive ComplianceSubscriber) use to trigger re-audits on change.

The sequence below shows one persona flowing through the pipeline from requirement load to serialised report.

sequenceDiagram
    participant Caller
    participant CompliancePipeline
    participant RequirementRegistry
    participant AIActClassifier
    participant ComplianceAuditor
    participant ConstitutionRegistry
    participant AuditFinding
    participant EvidenceGraph
    participant ComplianceReport
    participant EventBus

    Caller->>CompliancePipeline: audit(spec)
    CompliancePipeline->>RequirementRegistry: all_requirements()
    RequirementRegistry-->>CompliancePipeline: list[ComplianceRequirement]
    CompliancePipeline->>AIActClassifier: classify_persona(spec)
    AIActClassifier-->>CompliancePipeline: RiskCategory
    CompliancePipeline->>ComplianceAuditor: audit_persona(spec)
    loop for each requirement
        ComplianceAuditor->>AuditFinding: new(status, evidence, remediation)
    end
    ComplianceAuditor-->>CompliancePipeline: list[AuditFinding]
    CompliancePipeline->>ConstitutionRegistry: check_constitution_compliance(spec)
    ConstitutionRegistry-->>CompliancePipeline: ConstitutionResult
    CompliancePipeline->>EvidenceGraph: construct_graph(findings)
    EvidenceGraph-->>CompliancePipeline: DAG
    CompliancePipeline->>ComplianceReport: generate(findings, graph, risk)
    ComplianceReport-->>CompliancePipeline: ComplianceReport
    Note over EventBus: emits compliance.audited
    CompliancePipeline->>EventBus: publish(compliance.audited)
    CompliancePipeline-->>Caller: ComplianceReport

Failure modes are mostly recoverable. An unknown persona category falls through AIActClassifier to RiskCategory.MINIMAL with a warning logged, not an exception. The constitution check can return a ConstitutionResult.NOT_APPLICABLE if the persona has no declared constitution tier; the pipeline treats this as passing. Evidence-graph construction requires at least one PASS finding to anchor the DAG — if all findings fail, the graph is built as a disconnected set of remediation nodes rather than raising. Production instrumentation wraps audit_persona with a @traced span and subscribes to compliance.audited for drift detection; ComplianceSubscriber listens for upstream persona.updated events and re-triggers the pipeline automatically.

The ComplianceReport serialises to YAML plus a Graphviz-renderable DAG, and both are emitted as payload attachments on the compliance.audited event so downstream systems (dashboards, audit log sinks) do not need to re-read from disk. For CI integration the report carries a boolean is_compliant that gates the build.

Steps in detail

  1. Caller to CompliancePipeline: audit — A caller (CLI, subscriber, or scheduler) passes a PersonaSpec to the pipeline.
  2. Pipeline to RequirementRegistry: all_requirements — The registry returns the full list of ComplianceRequirement rows loaded from eu_ai_act_requirements.yaml and the NIST crosswalk.
  3. Pipeline to AIActClassifier: classify_persona — The classifier inspects the persona's category and tags to assign one of four RiskCategory values.
  4. Pipeline to ComplianceAuditor: audit_persona — The auditor enters its per-requirement loop.
  5. ComplianceAuditor to AuditFinding: new (loop) — For each requirement the auditor constructs an AuditFinding carrying status (pass/fail/na), evidence pointers, and remediation text.
  6. Pipeline to ConstitutionRegistry: check_constitution_compliance — The constitution registry layers tier-based checks (hard-stop, mandatory, preferred) on top of the regulatory findings.
  7. Pipeline to EvidenceGraph: construct_graph — The findings are assembled into a DAG where edges encode "evidence supports requirement" relations, enabling traceability queries.
  8. Pipeline to ComplianceReport: generate — A ComplianceReport is composed from findings, constitution result, evidence graph, and risk category.
  9. Pipeline to EventBus: publish(compliance.audited) — The event carries the report summary and the persona ID as its correlation key.
  10. Pipeline to Caller: ComplianceReport — The full report is returned for CI gating, dashboard rendering, or archival.

See also

  • Entry point: src/fcc/compliance/auditor.py:48
  • Pipeline orchestrator: src/fcc/compliance/pipeline.py
  • Related class diagram: ../class-diagrams/compliance-model.md
  • Related event types: src/fcc/messaging/events.pyEventType.COMPLIANCE_AUDITED