The Compliance console

Compliance is a top-level section of the Admin UI sidebar (scale icon, after Governance), visible to tenant admins with the compliance:read permission. One shell hosts nine pages as tabs, with a framework switcher at the top: EU AI Act by default, then every framework in the registry. The choice is remembered per browser; pages that are framework-bound show the selected framework’s view of the same evidence log.

Wording in the console

The console’s copy is pinned by a vocabulary test: a good result reads sealed, witnessed, recomputed, consistent, met (n of m) — never “verified”, “certified”, “compliant”, “guaranteed”, “pass”, “approved” or “tamper-proof” as a claim. Provision strings carry “not legal advice”.

Old deep links keep working: the former Posture leaf (compliance) lands on Overview, the EU AI Act board (eu-ai-act) on Obligations with the EU AI Act selected, and the ISO 42001 sub-tab on Obligations with ISO/IEC 42001 selected.

Overview

Per framework, readiness per AI System: its classification and role, whether the profile is declared and sealed, obligations in force and upcoming (dated), statement counts by basis — recomputed and judged side by side, never summed — the tenant log’s latest head grade (standalone / self_witnessed / witnessed / plural) and the latest Evidence Report. Around it: the framework’s dated timeline, the undetermined declarations as a to-do list, witness health, record lag and open capture_gap items. Counts, never verdicts: nothing on the page says a system is anything.

Frameworks

The registry: every framework with its catalog version, kind, jurisdiction, the verified-against-instrument flag (catalogs that were not are flagged in amber), retention floors and incident deadline rules, the tagged rows count — and the enable switch per tenant. Below the table, the selected framework’s catalog: its dated versions, role and classification vocabularies, and floors by classification.

Enabling a framework is the same tenant switch the compliance tagging engine reads, so the page also carries request-log tagging for the selected framework: how many request-log rows carry each of its tags in the window (7, 30 or 90 days), what gets tagged, what an auditor asks for, and — for GDPR Article 30 and HIPAA, where the evidence is a per-call list — Export for auditor (CSV). A framework without tags says so. There is one switch per framework: the table’s.

Profiles

The AI System fleet (the same list as the AI Estate — an AI System is a resource group of type ai_system) with each system’s classification, active frameworks and effective retention floor. Selecting a row opens the compliance profile editor: the neutral core plus the selected framework’s facts. Each save shows the sealed declaration it produced — or “not sealed” with the reason, when the core could not seal it. Documentation export is available per system.

Obligations

The selected framework’s obligations, dated. The AI System selector chooses whose:

• One AI System — its obligations grouped In force, Upcoming and Not applicable, each row with applies_from, the worst statement status over the window and the per-basis counts. undetermined rows are to-dos in amber naming the missing declaration, and they stay in the dated groups. Selecting a row opens its evidence under the row.
• All systems — the Board (the default): one row per obligation with the systems in scope, grouped the same way; or the Matrix, system × obligation, for comparing systems side by side. Each cell shows the worst statement status and per-basis counts.

Changing the system does not recompute anything: one evaluation feeds every view. The drill-in lists every statement with its basis chip (RECOMPUTED · JUDGED · INDICATOR · DECLARED), n of m, detail, the limit text, citations to records, and a cross-link showing the same evidence under the other frameworks that cite it.

Evidence Ledger

The record explorer: filter by AI System, verdict (all fourteen), kind, surface, window and run; a verdict distribution strip for the same window; the tenant log with its heads and receipts (grade per witness); disclosure records; and bundle export. Clicking a record opens the record dialog: the record JSON, the Signed Statement (copyable), its log position, its RFC 6962 inclusion proof, and Verify, which asks the core to recompute the record id, check the signature and run the semantic rules — findings grouped by severity; only errors gate the result.

Human Oversight

Oversight assignment per system; approvals requested, decided and lapsed; the blind review queue (the judge’s answer is hidden until the reviewer grades); agreement per judged check with its interval and sample size; and movement indicators for approval latency and denial rate. See judged evidence.

Transparency

The AI-interaction notice configuration per tenant and per AI System — text per locale, surface, exemption assertion with its basis and rationale — with the notice evidence as n of m conversations, and the synthetic-content declaration with its stated limit (content-level marking is not provided). See transparency.

Reports

Daily rollups, weekly grades and monthly Evidence Reports per framework: generate, view, download the bundle, permalink into the offline verifier, countersignature status, and the catalog version each was computed under. See Evidence Reports.

Incidents

The incident register with per-framework deadlines and their status (open, due_soon, overdue, reported_on_time, reported_late), linked runs and inbox items, report and close actions, and the sealed event history. See incidents.

Elsewhere in the Admin UI

Settings → Tenant → Evidence

• Witnesses — platform witnesses (read-only unless you are a system admin) and this tenant’s own: kind (scitt / rfc3161), URL, operator label, pinned key, enabled, and the honest same_operator flag. Pins are validated per kind before saving.
• Evidence switches — salt_digests_default (salt content digests for every system that does not decide otherwise) and per_tenant_key.
• Keys — the key ids this tenant’s records are signed under (deployment and tenant, active and retired), and Rotate key — refused with per_tenant_key_disabled, and explained, while the tenant key is off.
• Log — the tenant log’s size, latest head and grade.

AI System detail → Compliance

This system’s declared profile, its obligations under the selected framework with the evidence statements each is shown against, and how many sealed records the ledger holds for it.

Run details → sealed steps

Every action record the run produced, in log order, with its verdict, derived effect mode and chain links (planned → confirms, awaiting_human → supersedes / expired), View record, and Bundle / Verify this run (a root_task_id bundle built by the core and checked by its verifier). An open half of a chain — a planned record nothing confirms, an approval nothing resolved — is shown as open: it is the may/did gap, and hiding it would make the run look more settled than the log says.

Inbox items

The Assurance Inbox gains five kinds from the evidence programme:

Kind	Raised when	Deep link
evidence_unwitnessed	a tenant running a high-risk system has a head older than an hour that is still standalone or self_witnessed	Settings → Evidence
capture_gap	governed actions in the last hour that should carry a sealed record do not; or a Control Plane seal hook (declaration, epoch boundary, run abort) failed	Evidence Ledger
judge_uncalibrated	judge–human agreement below 0.80 with a sufficient sample	Human Oversight
calibration_stalled	reviews queued, none graded for 14 days	Human Oversight
incident_deadline	an incident deadline is due within 24 hours or passed	Incidents

Items follow the inbox’s dedup convention (one open item per fingerprint, bumped on recurrence); the compliance scheduler evaluates them every 15 minutes.