Skip to main content
The Compliance Command Center shows two complementary postures, kept as two distinct sections on one dashboard:
  • Evidence integrity — every figure recomputed from a signed, hash-linked chain your products export. This is the proven-not-asserted posture, verifiable offline.
  • Live service health — whether each product is actually up right now, polled on demand.
Evidence answers “is the record sound and verifiable.” Live health answers “is the service running.” A product can supply one or both. This page covers the live service bridge: how a product self-registers so the console can poll its health and show it live.
The bridge mirrors the Substrate 2 control plane contract on purpose, so the same small pattern plugs a product into either control plane. The Command Center is the control plane for the Health and Legal estate; Substrate 2 is the control plane for payments and trust.

The contract

A product joins with two things, and nothing more:
  1. A /health endpoint returning HTTP 200.
  2. One self-register call on bootPOST /v1/services with a service token.
The console then polls that /health on demand and folds the result into the Live service health panel. The product’s evidence export, if it has one, is unchanged: live health is added alongside it, never in place of it.

The service token

Registration is gated by a dedicated service token, deliberately separate from the console’s role-based login. It is narrowly scoped: it can register and remove services, and nothing else. Set it explicitly with COMMAND_CENTER_SERVICE_TOKEN, or let the console bootstrap one on first run into <COMMAND_CENTER_DATA_DIR>/command-center-service-token (written 0600):
# read the bootstrapped token
TOKEN=$(cat ./data/command-center-service-token)

Records Vault: the worked example

Records Vault ships a serve layer that self-registers on boot. Point it at the console with the CCC_HUB_* environment variables and run it:
CCC_HUB_URL=http://localhost:8200 \
CCC_HUB_TOKEN=$TOKEN \
CCC_HUB_NAME=records-vault \
CCC_HUB_SELF_URL=http://records-vault:8000 \
algovoi-records-vault-serve
CCC_HUB_SELF_URL is the address the console uses to poll the product’s health, so it must be the product’s own reachable URL on your network. On startup the vault registers itself; if the console is absent or unreachable the registration is skipped and the vault still boots. Confirm it joined and is live:
curl -s http://localhost:8200/v1/services            # registry: the vault is listed
Then sign in to the console: the dashboard’s Live service health panel shows records-vault as Live, beside the Evidence integrity panel that re-verifies the evidence the vault exports.

Add any product

Any service, in any language, joins the same way. It needs a /health endpoint returning 200 and one call on boot:
curl -X POST http://localhost:8200/v1/services \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"your-product","type":"product",
       "base_url":"http://your-product:9000","health_path":"/health"}'
A Python product can copy the bundled hub_client (~50 lines, standard library only) and call register_from_env() on startup; a non-Python product makes the same single request directly. There is no shared SDK to adopt and no outbound dependency: the product makes one call, the console does the rest.

On-demand polling

The console polls health when the dashboard is loaded or /api/services is called, not on a background loop. A product that is down reads as Down, never as an error, so a failed poll never breaks the console. Registrations and removals are appended to the console’s Falcon-signed, hash-linked audit log, so which products were bridged, and when is itself offline-verifiable evidence.

Command Center bridge API

EndpointPurpose
POST /v1/servicesregister a product (service token)
GET /v1/serviceslist registered products
DELETE /v1/services/{name}remove a product (service token)
GET /api/serviceslive health across all registered products (signed-in)
Everything is self-hosted and offline; the console makes no outbound calls of its own beyond polling the health endpoints you registered.

See also