PLATFORM / EVIDENCE & COMPLIANCE

Name the regulation. Then show the record.

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.

Hash-chained audit ledger Evidence mapped to named controls Coverage stated per control
EACH ENTRY CARRIES THE HASH OF THE ENTRY BEFORE IT SEQ 4412 sha-256 a91f…7c02 prev_hash linked SEQ 4413 sha-256 3d5b…11ae prev_hash linked SEQ 4414 sha-256 c07e…9f31 prev_hash linked Rewriting entry 4413 changes its hash, so 4414 no longer links to it. Tamper-evident — the break is detectable, not preventable. Order-bound, append-only. No raw prompts, no model outputs.

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.

automaticpartialmanual_attestationnot_assessed

THE EVIDENCE LAYER

A record an assessor can examine, and a map that says what it proves.

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.

LEDGER

Hash-chained audit ledger

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 deployment
COLLECTION

Evidence derived from live state

A 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, idempotent
MAPPING

Every control carries a coverage status

Controls 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.

four honest buckets
ATTESTATION

Attestation you can actually chase

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, history
EXPORT

Reports someone can take away

Template-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 · html
SIGNING

Signed evidence bundles, per deployment

Ed25519 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 default
Stated precisely Governance actions are recorded in a hash-chained, tamper-evident audit ledger.

Each 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.

REGULATORY PROGRAMS AND CONTROL LIBRARIES

The regulations we will name, and exactly what naming them buys you.

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 The framework carries 72 subcategories across GOVERN, MAP, MEASURE and MANAGE; this pack covers 53 of them. Seeded coverage across those 53 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.

COMPLIANCE

Eight frameworks, and a per-control statement of what we can actually evidence.

Governed actions are mapped to the controls an assessor asks about. What makes that useful is not the number of frameworks — it is that every control says which of three things it is.

SOC 2 Type II ISO/IEC 42001 NIST AI RMF 1.0 EU AI Act GDPR HIPAA PCI DSS NIST CSF
Declared coverage on the two AI frameworks On NIST AI RMF, of the 53 subcategories this pack covers out of the framework’s 72, zero are marked automatic, 15 are partial and 38 are manual attestation. On ISO/IEC 42001, zero of 35 clauses are automatic, 6 are partial and 29 are manual attestation. The automatic band has no width on either, which is the point. COVERAGE AS THE PACKS THEMSELVES DECLARE IT AUTOMATIC PARTIAL MANUAL ATTESTATION NIST AI RMF 1.0 53 OF 72 COVERED 15 PARTIAL 38 MANUAL 0 AUTOMATIC ISO/IEC 42001 35 CLAUSES 6 PARTIAL 29 MANUAL 0 AUTOMATIC THE AUTOMATIC BAND HAS NO WIDTH ON EITHER. THAT IS NOT AN OMISSION.
Per control
What it means, and why we mark it
Automatic
A live GovernorAI signal evidences the control on its own — the decision record, the approval, the kill switch, the policy engine.
Partial
A GovernorAI signal contributes, and a human still has to supply the rest. The control is not claimed as covered.
Manual attestation
Nothing we produce evidences it. The control asks for documented procedure or management commitment, and the pack says so rather than leaving you to discover it in an audit.

The number we would lead with if we were selling this badly. On both AI frameworks, the count of controls marked automatic is zero. NIST AI RMF: the pack covers 53 of the framework’s 72 subcategories — 15 partial, 38 manual attestation. ISO 42001: 6 of 35 clauses partial, 29 manual. The packs say why in their own source — every control in these standards carries a human-judgment component, and we will not mark as automatic a control an assessor would still expect a person to attest. See what the record looks like →

What is true today, stated exactly. Control status is computed from the same governed-action record the enforcement produced — not assembled at audit time from screenshots. That computation runs when it is asked to run. A scheduled sweep exists and ships turned off. Event-driven recomputation is being built and is not here yet.

THE CLAIM WE ARE NOT MAKING YET

We will call it continuous compliance when these six things are true. Not before.

We would rather publish the definition than the phrase. Here is the bar we have set ourselves, written down before we clear it so that you can hold us to it.

01The runtime path is complete

Recomputation wired into decision processing, durable stores and migration in place, the audit-chain cursor consuming, and the posture API returning its conflict semantics.

02The backstop actually runs

The scheduled sweep enabled and verified in a deployed environment, overlapping safely with event-triggered recomputes, and proven to recover after worker, database and deployment restarts.

03Freshness is bounded and published

A stated window inside which every key is recomputed, with cursor lag, dropped recomputes, stale assessments and failed cycles all exposed and alerted — and a published number, not an adjective.

04Tenancy and ordering are proven

Isolation enforced at the persistence and result boundaries, and duplicate, delayed, out-of-order and concurrent events all tested — including that a restart cannot regress an assessment to an older result.

05Coverage is real, per framework

For each advertised control: a registered trigger, an evaluator, the evidence it produces, and proof it runs in the deployment modes we claim. Where it does not, the control reports not assessed rather than implying compliance.

06A release gate enforces all five

Both paths active, zero unacknowledged drops, freshness within the published window, recovery after failover, cross-tenant isolation and evidence-chain verification — as a gate, not a checklist someone reads.

Until every one of those passes, this page says designed for continuous assessment and means exactly that. When they pass, this section is replaced by the freshness number and the scope it applies to. A compliance surface that reports a pass it cannot support is the failure this product exists to prevent — it would be a poor place to start making an exception.

WHAT THE RECORD LOOKS LIKE

One entry, and the entry before it.

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.

  1. sequence 84211

    prev_hash0000…genesis

    entry_hasha3f0…8c41

  2. sequence 84212

    prev_hasha3f0…8c41

    entry_hash9f2c…e18a

  3. sequence 84213

    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.

audit ledger entry · real field names, illustrative values
{
  "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"
}
chain verification · the answer carries its own scope
{
  "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
}

IN THE PRODUCT

The surface this page describes.

GovernorAI Demo Evidence Items view showing controls mapped to framework references with collected and pending evidence statuses
Evidence ItemsEach control mapped to its framework reference, with per-item status

Continue