PLATFORM / EVIDENCE & COMPLIANCE
Governance actions are recorded in a hash-chained, tamper-evident audit ledger, and that evidence is mapped to named controls under the EU AI Act, Colorado SB 24-205, GDPR, SOC 2, HIPAA, PCI DSS, ISO/IEC 42001 and the NIST AI RMF. Mapping evidence to controls is not certification, and this page is careful about the difference.
Each governance action carries a sequence number and the SHA-256 hash of the entry before it. Altering an entry breaks the link that follows it — which makes tampering detectable, not impossible.
THE EVIDENCE LAYER
Two jobs, kept separate on purpose. One is a durable, order-bound record of what GovernorAI governed. The other is a mapping from that record to the controls a framework asks about — with the coverage of every control stated rather than assumed.
Each governance action written to the audit store carries a sequence number and the SHA-256 hash of the entry before it. Verification walks the chain from an empty genesis hash and stops at the first row it cannot reconcile, naming that row.
live in every deploymentA standard evidence catalogue populates per account and derives its payload from real signals — audit-event volume, active policy count, enabled alert rules, registered agents. Items that no signal can produce are marked as document or screenshot uploads rather than filled in.
deterministic ids, idempotentControls in a framework pack resolve to one of four values: automatic, partial, manual_attestation, or not_applicable. A control is never returned as automatic if any part of it still needs a person to attest.
Recurring attestation campaigns assign each policy owner a task with a due date and a decision — still relevant, needs update, should retire, needs review — plus reject and escalate paths, overdue tracking, and a per-policy attestation history.
campaigns, tasks, historyTemplate-driven exports per framework in PDF, JSON, CSV or HTML across a date range, with a preview of the sections and the evidence each one carries before the job runs.
pdf · json · csv · htmlEd25519 and Merkle batch manifests sealed in the gateway pipeline. Available per deployment and off unless an operator turns evidence signing on — it also requires a dedicated, non-shared gateway and a persistent key store, or the gateway refuses to start rather than sign unverifiably.
not on by defaultEach entry carries a sequence number and the hash of the entry before it; verification walks from genesis and names the first row that does not reconcile. A passing result also reports how many rows predate the tenant-binding hash format, because for those rows a valid chain says nothing about which tenant the event belonged to. Signed Ed25519/Merkle evidence bundles are available per deployment — they are not default-on.
Naming a regulation on this page means GovernorAI has a workspace, a control library, or an evidence mapping for it. It does not mean that running GovernorAI makes you compliant with it, and no framework named here is automatically or fully covered.
The product is built to say so out loud. Every control in a framework pack is classified automatic, partial, manual_attestation or not_applicable, and for the AI-governance standards most of them are manual: the ISO/IEC 42001 pack seeds zero automatic clauses, and the NIST AI RMF pack seeds zero automatic subcategories because every one of them has a human-judgment component. Where GovernorAI cannot prove a control, it names the fields you have to attest to yourself instead of scoring it.
A certification is issued by an auditor, a certification body, or a notified body, against their own opinion. GovernorAI is none of those and produces no audit opinion. What it produces is a record, and a mapping an assessor can examine.
REGULATORY PROGRAMS AND CONTROL LIBRARIES
Each row is a surface that exists in the product. The third column is deliberately the narrow claim — what a GRC team gets, not what the regulation demands in full.
| Regulation or standard | Where it lives | What this gives you |
|---|---|---|
| EU AI Act | /compliance/programs/eu-ai-act | Register an AI system, get a risk tier — unacceptable, high, limited or minimal — from a scored classifier, and track obligations against a requirement library that names Articles 6, 9–16, 26, 50 and 52. Human-oversight configuration, transparency records, and per-system bias reports attach to the same record. The classifier scores category, purpose and deployment region: first-pass triage for counsel to confirm, not a legal determination. |
| Colorado SB 24-205 (Colorado AI Act) | /compliance/programs/colorado-ai-act | High-risk system records across the seven consequential-decision domains — employment, education, financial, government, healthcare, housing, legal — plus documented impact assessments covering bias risk, mitigation steps, human oversight, consumer notice and appeal mechanism. Each obligation can be linked to a specific audit event as its evidence. |
| GDPR — data-subject operations | /privacy | Right-of-access exports, erasure requests with an explicit confirm step and a retry path, consent grant and withdrawal, retention policies, and data-residency configuration. Erasure is gated by the legal-hold registry and fails closed: if the gate cannot prove there is no hold, the erasure is blocked rather than allowed. |
| SOC 2, GDPR, HIPAA, PCI DSS — live control assessment | /compliance | Controls scored from real system state — audit-event volume, active policies, enabled alert rules, registered agents — rather than from a questionnaire. Controls resolve to pass, fail, partial or not_assessed. The EU AI Act is deliberately excluded from this assessor and handled as a programme workspace instead, because platform signals do not answer its questions. |
| ISO/IEC 42001:2023 | /compliance/programs/frameworks/iso_42001 | All 35 clauses of the AI management system, each with a coverage status and, where GovernorAI cannot prove it, the named fields you must attest to by hand. Seeded coverage is 0 automatic, 6 partial, 29 manual attestation — this is a management-system standard, and most of it is organisational evidence no tool can produce for you. |
| NIST AI RMF 1.0 | /compliance/programs/frameworks/nist_ai_rmf | All 53 subcategories across GOVERN, MAP, MEASURE and MANAGE. Seeded coverage is 0 automatic, 15 partial, 38 manual attestation. The partial ones are the subcategories a live GovernorAI signal genuinely contributes to — audit log, kill switch, policy engine, approval workflow, anomaly detection, RBAC. |
| NIST SP 800-53 Rev 5 | /compliance/programs/frameworks/nist_800_53 | A control pack with the same coverage classification, assessment runs, findings and per-control attestation as the others. Useful where an agent programme has to answer to an existing federal control catalogue rather than a new AI-specific one. |
| Cross-framework control references | /compliance/scorecards | A seeded map of equivalent and overlapping controls between SOC 2, GDPR, HIPAA and PCI DSS, each with a stated relationship and rationale, so evidence gathered for one control can be pointed at its counterpart instead of collected twice. It is a stated mapping with its reasoning attached, not a proof of equivalence. |
| Legal hold and records preservation | API only — /api/v1/legal-holds | Place an account-, subject- or resource-scoped preservation hold that blocks erasure of the covered records until it is explicitly released. There is no legal-hold console: today the registry is driven through the API, and the only place a hold surfaces in the interface is as a legal-hold flag on a retention policy in the Privacy Center. |
Two things this table does not say. It does not say a regulation is satisfied — see the honesty note above. And it does not say every surface has a screen: the legal-hold row is marked API only because that is what it is, and we would rather write that than let a reader assume a console exists.
WHAT THE RECORD LOOKS LIKE
The ledger is the primary tamper-evidence mechanism and it is live wherever GovernorAI runs — no flag, no separate plane. The mechanism is unglamorous, which is the point: each entry commits to its predecessor, so a change anywhere in the history stops reconciling.
prev_hash0000…genesis
entry_hasha3f0…8c41
prev_hasha3f0…8c41
entry_hash9f2c…e18a
prev_hash9f2c…e18a
entry_hash41b7…07d5
Change any field in entry 84212 and its entry_hash no longer matches the prev_hash recorded in 84213. Verification walks from genesis and reports the first row it cannot reconcile.
{
"id": "evt_8f21c4a0",
"sequence_number": 84213,
"timestamp": "2026-03-04T09:12:44Z",
"account_id": "acct_7c11",
"action": "policy.decision",
"resource_type": "agent",
"resource_id": "billing-copilot",
"prev_hash": "9f2c…e18a",
"entry_hash": "41b7…07d5"
}{
"status": "verified_valid",
"entries_count": 84213,
"last_hash": "41b7…07d5",
// how many rows predate the tenant-binding hash format
"legacy_entries": 0,
"tenant_bound": true
}Chain verification tells you that the entries the ledger holds still reconcile, and names the first row that does not. It cannot tell you that everything worth recording reached the ledger: that depends on which seams are integrated and what the deployment actually routes through them.
Verification also reports how many rows predate the tenant-binding hash format, and refuses to assert tenant binding when it cannot. A passing chain over those older rows does not by itself establish which tenant an event belonged to, and we would rather ship that qualification alongside the answer than bury it.
IN THE PRODUCT
IN THE PRODUCT
