diff --git a/docker-compose.yml b/docker-compose.yml
index 05ee259..a52093c 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -1140,8 +1140,8 @@ services:
       # lands root-owned and the engine runs as UID 1000.
       DFE_GITOPS_ENABLED: ${DFE_GITOPS_ENABLED:-true}
       DFE_GITOPS_LOCAL_PATH: ${DFE_ENGINE_CONFIG_DIR:-/app/config}/deploy-repo
-      # HyperDX's control surface: the engine confirms the fork's default team and
-      # seeds its connections and sources. Both follow the resolved footprint
+      # HyperDX's control surface: the engine fans the sources it deploys onto
+      # every HyperDX team. Both follow the resolved footprint
       # (scripts/resolve_profile.py), so one DFE_HYPERDX_ENABLED governs the
       # HyperDX containers and the engine that drives them.
       DFE_HYPERDX_ENABLED: ${DFE_HYPERDX_RESOLVED:-false}
diff --git a/docs/configuration.md b/docs/configuration.md
index d8cd90c..bad15ee 100644
--- a/docs/configuration.md
+++ b/docs/configuration.md
@@ -308,7 +308,7 @@ Off by default. `DFE_OTEL_ENABLED=true` (or a profile declaring `otel: true`, as
 
 Off by default. `DFE_HYPERDX_ENABLED=true` starts `hyperdx` (API + App), the `dfe-hyperdx-proxy` that fronts both origins, a one-shot `dfe-dashboards` that copies the engine's shipped dashboards into a volume, plus `hyperdx-ferretdb` and `hyperdx-postgres`, sharing the always-on ClickHouse.
 
-HyperDX runs in `oidc-proxy` mode, as it does on Kubernetes: it verifies the engine's ES384 token against the engine's JWKS, and a caller carrying none is unauthenticated. Signing in to the console is what signs a browser in here -- dfe-ui mirrors the session into a `dfe_token` cookie, and cookies ignore ports. The engine identifies with a service token of its own, which is how the team gets seeded with the connection and sources from `config/hyperdx/default-sources.json` before anyone logs in, and how a source added through the console reaches HyperDX at all.
+HyperDX runs in `oidc-proxy` mode, as it does on Kubernetes: it verifies the engine's ES384 token against the engine's JWKS, and a caller carrying none is unauthenticated. Signing in to the console is what signs a browser in here -- dfe-ui mirrors the session into a `dfe_token` cookie, and cookies ignore ports. The engine identifies with a service token of its own, which is how a source added through the console reaches every HyperDX team. That token's team, `DFE_HYPERDX_TEAM`, holds no connection and no sources, because HyperDX seeds a team only from a person's login, never from the service token. Every other team gets its connection and sources on its members' first login, from the engine's answer for that member: `main` and `hunts` everywhere, plus the otel and `clickhouse_system` sources on a platform team, and the shipped dashboards those sources can render. From hyperi-io/dfe-hyperdx#106 on, a login the engine gives no connection is retried on a later request. `config/hyperdx/default-sources.json` seeds nothing in `oidc-proxy` mode, only in `header-dev`.
 
 The same toggle points the engine at HyperDX: with it on, the engine receives `DFE_HYPERDX_ENABLED=true` and `DFE_HYPERDX_BASE_URL=http://hyperdx:8000`, so its `/api/v1/hyperdx/*` surface answers instead of returning `503 hyperdx_absent`.