Compliance Command Center

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.

​

Proven, not asserted

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 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, 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 is the first product to bridge in. See Plug a product into the Command Center for the howto.

​

How it fits

​

Availability

A self-hosted Enterprise product, available from the 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 — bridge a product’s live health in
• Records Vault — the evidence this manages
• Bring Your Own Keys — key custody across the estate
• .epi Evidence Export — hand portable evidence to a third party