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

# Plug a product into the Command Center

> Any product with a health endpoint joins the Command Center live service bridge with one set of environment variables, and self registers on boot.

The [Compliance Command Center](/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.

<Note>
  The bridge mirrors the [Substrate 2 control plane](/substrate-2-addons) 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.
</Note>

## The contract

A product joins with two things, and nothing more:

1. **A `/health` endpoint** returning HTTP 200.
2. **One self-register call on boot** — `POST /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`):

```bash theme={null}
# 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:

```bash theme={null}
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:

```bash theme={null}
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:

```bash theme={null}
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

| Endpoint                     | Purpose                                                  |
| ---------------------------- | -------------------------------------------------------- |
| `POST /v1/services`          | register a product *(service token)*                     |
| `GET /v1/services`           | list registered products                                 |
| `DELETE /v1/services/{name}` | remove a product *(service token)*                       |
| `GET /api/services`          | live 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

* [Compliance Command Center](/compliance-command-center) — the console this plugs into
* [Records Vault](/records-vault) — the worked example, the first product to bridge
* [Substrate 2 Addons](/substrate-2-addons) — the same contract for the payments and trust control plane