Audit Primer

An FCC audit is not a single artifact; it is a bundle of four linked documents that together let a policy reviewer answer the question "is this AI system fit for this deployment context?" This page walks through each document in the bundle, shows an example excerpt, and tells you what to look for first.

The four artifacts

1. ComplianceReport (JSON) — machine-readable, produced by fcc compliance-audit. Contains findings keyed to EU AI Act requirements and NIST AI RMF subcategories.
2. Evidence Graph (JSON-LD) — a linked-data document showing which evidence items back which requirements. This is the most defensible artifact in any legal challenge.
3. Model Cards (Markdown, one per persona) — human-readable; follows Mitchell et al. 2019. Lives in docs/model-cards/.
4. Risk Heatmap (ASCII or PNG) — a visual summary. Useful for briefings, not for legal evidence.

The FCC CLI emits all four from a single fcc compliance-audit --full run. As a policy reviewer you rarely need to invoke the CLI — you receive the bundle.

Reading a ComplianceReport

A report header looks like this:

{
  "report_id": "audit-2026-04-23-crater-municipal",
  "generated_at": "2026-04-23T14:22:10Z",
  "deployment": "crater-v0.2.0",
  "regulation_set": ["eu_ai_act_2024_1689", "nist_ai_rmf_1_0"],
  "summary": {
    "total_requirements": 256,
    "compliant": 211,
    "partial": 28,
    "non_compliant": 9,
    "not_applicable": 8
  },
  "risk_classification": "high"
}

First thing to check: non_compliant and partial. A healthy deployment has zero non-compliant findings for its risk class and a shrinking list of partials with remediation dates. A deployment with more than a handful of non-compliant findings in its risk class should not be signed off without written justification.

Reading a finding

Each finding points to at least one article and at least one evidence item:

{
  "finding_id": "F-2026-04-23-017",
  "requirement": "eu_ai_act.art_10.data_quality",
  "nist_crosswalk": ["measure_2.3", "measure_2.7"],
  "status": "partial",
  "evidence": ["ev_dataset_card_crater_02", "ev_model_card_legal_finder"],
  "remediation": {
    "owner": "crater-maintainers",
    "due_date": "2026-06-01",
    "description": "Add provenance for 3 statute corpora flagged by ev_dataset_card_crater_02."
  }
}

Policy-useful fact: the nist_crosswalk field means you can discuss this finding in either regulatory framework without re-arguing the mapping. FCC's 29-subcategory crosswalk is the authoritative source.

Reading the evidence graph

The evidence graph is a JSON-LD document. You do not need to parse it; you need to know what questions it can answer:

• "Show me every requirement backed by fewer than two evidence items." (These are thin findings.)
• "Show me every evidence item older than 180 days." (These are stale.)
• "Show me every finding whose evidence items come from the same persona." (Possible separation-of-duties concerns.)

The technical team can run each query in seconds with the packaged CLI. The policy value is that the queries are standard, so two independent reviewers using two different tools will return identical answers.

Reading a model card

A model card is one Markdown file per persona and follows a fixed structure:

• Intended Use — what the persona is meant to do
• Out-of-Scope Uses — what it should not be used for
• Training Data / Inputs — what the persona consumes
• Performance — benchmark results from the CLEAR+ suite
• Ethical Considerations — documented bias, privacy, safety concerns
• Caveats and Recommendations — known gotchas

For policy work, the Out-of-Scope Uses and Ethical Considerations sections are load-bearing. They are the explicit self-imposed limits of the system's designers. Any deployment that violates the stated out-of-scope uses is prima facie a governance failure.

The risk heatmap

The heatmap is a quick visual. It shows, for each persona, the risk category and the number of open findings. A row of green with one or two yellows is a healthy deployment. A row of reds is not.

Reviewer checklist

When a compliance bundle lands on your desk:

1. Open report_summary.json first. Check risk_classification and summary.
2. If any non_compliant exists, open those findings in order of severity.
3. For each non-compliant finding, read the linked model card's Out-of-Scope Uses.
4. Cross-check the NIST subcategory using the crosswalk table.
5. Flag anything in the evidence graph older than your policy shelf-life (commonly 180 days).
6. Ask the technical team for a remediation timeline before sign-off.

Where next

Now that you can read an audit, proceed to Policy Brief Generation to turn these artifacts into a one-page brief, or to the Compliance Walkthrough for an end-to-end traced example.