What your auditor actually receives.

• Customer org name, license_id, billing period covered
• Quarterly window dates + total AI commits attested
• "Posture changed since last quarter" delta (with cited rows)
• Auditor sign-off block (your auditor signs this section, not us)

Auditor reads this first. If the exec summary doesn't answer "is your AI governance program credible," they go deeper. If it does, the rest is supporting evidence.

• Issuer pubkey fingerprint (SHA-256 of SPKI-DER)
• Per-install identity-keypair fingerprints (every machine that ran fastpace activate in the window)
• Audit-chain head hash + entry count per install
• fastpace verify output for each install (chain integrity status)
• Run-manifest signature verification rate (% of AI calls with valid signatures)

Maps to SOC 2 CC6.1 / CC6.7 (logical access + cryptographic protections). Auditor can independently verify the chain integrity using the included script — no trust in fastpace required.

• NIST AI RMF (GOVERN / MAP / MEASURE / MANAGE) — 24 sub-controls mapped
• ISO/IEC 42001 (AI management system) — 18 sub-controls mapped
• EU AI Act high-risk-system requirements (Articles 9–17) — 11 controls mapped
• SOC 2 Type II (CC4.1 monitoring, CC6.1 access, CC7.1 detection, CC8.1 change-management) — 14 controls mapped
• ISO 27001 Annex A (A.5–A.8 organizational + people + physical + tech controls) — 22 controls mapped
• Per-control: which fastpace primitive provides evidence + sample of evidence

The single most-asked-for artifact. Customer's auditor references this matrix during fieldwork; saves ~40 hours of "show me how X maps to Y" cycles.

• Every model invoked in the window (provider, family, version, runtime)
• Per-model invocation count + total tokens
• Provenance trailers linking each AI commit to the model that produced it
• Sub-processor attestation (which AI provider saw what data class)
• Air-gap status (which installs run with no outbound AI calls)

Maps to the EU AI Act's "transparency about training and deployment data" requirements. CISO uses this for sub-processor reviews. CycloneDX-AI is the OWASP draft format — your downstream customers can verify it without bespoke tooling.

• Every signed run manifest in the quarter (1 row per AI tool call)
• Every audit-chain entry (1 row per significant event: tool call, agent grant, exception, hook decision)
• Tamper-evidence: hash-chain integrity verified per install
• Sensitivity-tag distribution (what % of AI calls saw what data class)

Maps to SOC 2 CC4.1 (monitoring) + CC7.1 (detection of anomalies). Sensitivity tags are the CISO's answer to "did our AI agent see customer PII?"

• Active policy bundle hash (signed by your org's key, distributed to every install)
• Per-install policy-bundle reception confirmation (signed receipt)
• Exception ledger: every time-boxed override granted in the window
• Per-exception: who, when, risk tier (low / critical / irreversible / exfil-eligible), reviewer, expiry

Maps to SOC 2 CC8.1 (change management). The exception ledger is what auditors look for to assess "is the team using exceptions responsibly or as a default escape hatch?"

• Per-install AI-reliability score trend (F2.1 — where did AI-generated code stay vs. get reverted)
• Correction-rate per agent (which specialists are reliable, which are drifting)
• Fleet-wide reliability rollup (org-dashboard aggregate)
• Maturity score across the F4.12 24-cell rubric
• Quarterly delta vs. baseline

Maps to the EU AI Act Article 9 (risk management — continuous monitoring) and ISO 42001's "objective measurement of AI system performance" requirements. This is also the leading indicator the customer's board cares about.

• Every fastpace sub-processor (AI providers, infrastructure, payment, email)
• Purpose of each, data class accessed, region, retention
• DPA reference (a copy of each sub-processor DPA available on request)
• Change log: what changed in the quarter + 30-day notice acknowledgment

Required for GDPR Article 28(4) — sub-processor governance. Required for SOC 2 CC9.1 — vendor management. Customer's legal team often asks for this independently.

• Executive summary of the most recent annual pen test (under NDA)
• Findings count by severity (critical / high / medium / low)
• Per-critical / per-high finding: status + remediation timeline
• Re-test verification (where applicable)

Required for SOC 2 CC4.1 (monitoring) + CC7.1 (security incident detection). Customer's security review process typically asks for the most recent pen test report under NDA.

• Every evidence request opened in the window (initiator, scope, status)
• SLO compliance: % of requests fulfilled within the 5-business-day SLO
• Lifecycle transitions per request (requested → in-progress → fulfilled → closed)
• Signed envelope per fulfilled request

Demonstrates operational maturity — the customer's own auditors and downstream customers can request evidence on-demand and the fulfillment process is measurable.