> ## Documentation Index
> Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt
> Use this file to discover all available pages before exploring further.

# Compliance Command Center

> Self hosted management console over your AlgoVoi estate: ingests exported evidence, re-verifies every signed chain offline, and exports an auditor pack.

<Note>
  **Also in the on-prem suite.** This product is included in the [AlgoVoi Compliance and Payments On-Prem Suite](/substrate-2), one commercial licence that unlocks and runs the complete self-hosted platform.
</Note>

Compliance dashboards usually ask you to *trust the vendor*. A green tick means the platform says you're
compliant — backed by its own attestation, in its own cloud. When your auditor, your regulator, or a
court asks "prove it," that green tick isn't evidence.

The **Compliance Command Center** is the opposite. It's a **self-hosted** web console that sits over your
AlgoVoi estate and shows one compliance-posture dashboard — where **every figure is recomputed from a
Falcon-1024 signed, hash-linked chain**. Nothing is asserted; everything is proven, and your auditor can
re-verify it themselves, offline, with no AlgoVoi software or service.

<Note>
  Sits above [Records Vault](/records-vault). It ingests the evidence your products already export — it
  adds no new system of record. Self-hosted on your infrastructure; air-gap capable.
</Note>

## Proven, not asserted

|              | Other Vendors                          | **Compliance Command Center**                        |
| ------------ | -------------------------------------- | ---------------------------------------------------- |
| Evidence     | Attestation + dashboards, vendor-trust | Every figure backed by a **signed chain**            |
| Verification | Trust the vendor                       | **Offline, public key only — re-verify it yourself** |
| Deployment   | SaaS                                   | **Self-hosted, air-gap capable, sovereign**          |
| Cryptography | Classical                              | **Post-quantum (Falcon-1024)**                       |

Change a single byte of any underlying evidence and the dashboard, the API, and the audit log all flag
it. The trust base for verification is two public libraries — no AlgoVoi code takes part.

## What it does

* **Aggregates your posture.** Records preserved, read-access events, active legal holds, consents, key
  rotations — each tile shows its value *and* its verification status.
* **Re-verifies, continuously.** Every signed chain across the ingested evidence is recomputed offline;
  a failure surfaces immediately.
* **Exports an auditor pack.** One click bundles the evidence plus a verification summary into an archive
  your auditor, regulator, or counterparty verifies independently.
* **Validates itself.** Export a signed **system-validation pack** (IQ, OQ, PQ) that shows the console is
  installed correctly and operating to specification, with its own audit chain and every ingested chain
  re-verified live at the moment of export. It supports your **21 CFR Part 11 section 11.10(a)** evidence,
  signed and offline-verifiable, and it ships its own standalone verifier so an inspector confirms it with
  no AlgoVoi software. A built-in value-add, not an extra.

## Operate the estate, not just observe it

The console is more than a read-only dashboard. From one place an operator runs the regulated-records
lifecycle directly, and every action is written to the signed console audit chain.

* **Records.** Browse every notarized record with its live chain-verification status, notarize a new
  record (encrypted at rest and RFC-3161 timestamped), and retrieve a stored document, which writes a
  signed read-access event.
* **Import.** Bring an existing document estate into the vault at scale, from a server folder, an SFTP
  drop, or an rsync target. The importer Merkle-batch-signs the estate with the console key while
  streaming at constant memory, and a folder watcher can import a standing feed whenever a drop folder
  goes quiet. Bulk volume never travels through the browser, so it is bounded by disk and hashing, not by
  an upload.
* **Legal holds.** Place and release litigation or investigation holds over a matter. A held record can
  never be purged, and a hold cannot be released before its preservation window elapses.
* **Retention and disposition.** A disposition queue lists records that have passed their retention window
  and sit under no hold. Disposition is deliberate and operator-driven, never automatic, and records
  preserved under an active hold are called out.
* **Evidence streams.** Every signed stream (consent receipts, chain of custody, key custody and rotation
  proofs, redactions, read-access) is surfaced with its own integrity check, each verifiable offline with
  the one published console public key.
* **Local accounts.** Administrators manage local accounts (add, re-role, remove) with guardrails that
  keep at least one administrator and stop an operator locking themselves out.

Sensitive actions take a fresh credential re-check: notarizing a record re-confirms your password inline,
and retrieving a document or releasing a hold requires a short-lived step-up confirmation.

## Hardened for exposure

The console is built to sit safely on a network, not only on a trusted appliance. Every response carries
a strict **Content-Security-Policy** that pins all content to same-origin, blocks framing
(`frame-ancestors 'none'`) against clickjacking, and constrains where forms may post, alongside
`X-Frame-Options`, `X-Content-Type-Options`, and a `no-referrer` policy. The **session and step-up
cookies are marked Secure** whenever the console is reached over HTTPS, directly or through a
TLS-terminating proxy, while staying usable over plain HTTP for a fully air-gapped install. Sign-in and
the step-up re-check have a **per-client brute-force backoff** that returns a short cool-off after
repeated failures, and every block is written to the signed audit chain. The post-login redirect is
constrained to same-origin paths, so a crafted link cannot bounce an operator off-site. All of this is on
by default, with no configuration.

## Two-factor authentication

Add authenticator-app two-factor to console sign-in. A user enrolls from the **Security** page by
scanning a QR code into an authenticator app (Google Authenticator, Authy, Microsoft Authenticator,
1Password, and so on), or by entering the setup key by hand, then confirming the current six-digit code.
Enrollment is **opt-in, then required**: once a user enrolls, every sign-in asks for the rotating code
after the password, and turning it off takes a fresh step-up. Codes are **RFC 6238 TOTP**, so there is no
SMS or email dependency and nothing leaves the appliance, keeping it fully air-gap friendly. Every
enroll, activation, disable, and two-factor sign-in is written to the signed console audit chain.

Two-factor is delivered as an optional add-on the console discovers automatically once installed, so you
turn it on per deployment without touching the console itself.

## SIEM audit forwarding

Stream the signed console audit chain to your SIEM as entries are appended, in the formats a SOC
expects: **RFC 5424 syslog**, **CEF** over syslog, and a generic **webhook** (JSON POST with an optional
bearer token). Every forwarded record carries the entry's `seq` and its `sha256` payload hash, so a SIEM
event ties straight back to the tamper-evident chain and your analysts can correlate or re-verify it.

It is **off unless you configure a sink**, so air-gapped installs forward nothing. Forwarding is
non-blocking (a slow or broken SIEM never stalls the console), best-effort (a sink failure is recorded
and retried but never breaks the signed audit append), and catches up on restart (anything appended
while a sink was down is backfilled). The Audit page shows a read-only forwarding-status card.

## Enterprise from day one

* **Role-based access.** Administrator, compliance officer, auditor, and read-only viewer roles govern
  who can see which evidence, run which reports, and export packs.
* **Single sign-on.** Authenticate against your directory — **LDAP / Active Directory** — with directory
  groups mapped to roles. Local accounts for fully disconnected operation.
* **Bring-your-own-key custody.** The console's own signing key can live in your **AWS KMS, HashiCorp
  Vault, or PKCS#11 HSM** — unwrapped only at the moment of signing, never at rest.
* **A signed console audit log.** Every console action — who signed in, who viewed what, who exported —
  is appended to a Falcon-signed, hash-linked chain. The console holds *itself* to the same standard:
  *who did what in the console* is itself offline-verifiable evidence.

## Scales with your estate

The console persists through a database you choose with a single setting. **SQLite** by default: one file,
no server, ideal for an air-gapped appliance. Or **PostgreSQL** for an enterprise deployment, the same
build with one variable changed and no second code path. Appends are constant time, and the dashboard
re-verifies only what has changed since it last looked rather than the whole history, so a console that has
been running for years stays responsive. The trust never depends on the database: every figure is signed
and content-addressed, so it verifies the same way offline whatever it is stored in.

Any AlgoVoi product that exports signed evidence bolts straight in. Drop its evidence into the watched
ingest directory and the console detects the chain type, re-verifies it, and folds it into one posture.
[Records Vault](/records-vault) and the rest of the estate become a single dashboard with no new system of
record.

## Live service health

Alongside the evidence posture, the console shows a second, distinct posture: **whether each product is
actually up right now**. A product self-registers on boot with one set of environment variables, the
console polls its `/health` on demand, and it appears on the dashboard in a **Live service health** panel
beside the **Evidence integrity** panel. The two are never conflated: evidence integrity answers "is the
record sound and verifiable," live health answers "is the service running."

This reuses the same small contract as the [Substrate 2 control plane](/substrate-2-addons), so one pattern
plugs a product into either: the Command Center is the control plane for the Health and Legal estate. A
product needs only a `/health` endpoint and one self-register call, gated by a dedicated service token that
is separate from the console login. Registrations are appended to the signed console audit log, so *which
products were bridged, and when* is itself offline-verifiable. [Records Vault](/records-vault) is the first
product to bridge in. See [Plug a product into the Command Center](/command-center-products) for the howto.

## How it fits

|             |                                                                                                   |
| ----------- | ------------------------------------------------------------------------------------------------- |
| **Below**   | [Records Vault](/records-vault) and the rest of your estate — preserve records as signed evidence |
| **This**    | the management layer — aggregate, re-verify, report, and export across the estate                 |
| **Custody** | composes with [Bring Your Own Keys](/bring-your-own-keys)                                         |

## Availability

A self-hosted **Enterprise** product, available from the
[suite store](https://api.algovoi.co.uk/suite-store) (`AV-CCC`). Installs token-gated from the AlgoVoi
private index — including fully **air-gapped**, with no PyPI. Runtime-licensed, fail-closed.

## See also

* [Plug a product into the Command Center](/command-center-products) — bridge a product's live health in
* [Records Vault](/records-vault) — the evidence this manages
* [Bring Your Own Keys](/bring-your-own-keys) — key custody across the estate
* [.epi Evidence Export](/epi-evidence-export) — hand portable evidence to a third party