"The Force" is the collection of operational apps that run as their own services in-cluster and are surfaced inside the dashboard as iframes. The dashboard does not own them — it owns the integration: where they live, whether they're configured, whether they're reachable, and the embedded chrome around them.

Each embed has the same shape: an env-driven URL, a "configured?" check exposed via src/lib/forceEmbeds.ts, a sidebar readiness tile in the "The Force" group, and a full-bleed iframe page under /the-force/<name>.

The embeds

Medusa (Hydroid) — planned

Medusa (full name Medusa Hydroid) is the contact-fusion engine, and the next Force page to be built — it does not exist in the dashboard yet. Its job: ingest the UXV measurements gathered and calibrated during TaskForce-X sessions (via the Imp Intel plane), run correlation and fusion — weighting each reading by the variance learned during calibration, per the fusion math in .settings/docs/4817/research/ (Korb, 2026-05-20) — and publish unified contacts to the COP over the MQTT/TBMQ backbone.

In mesh terms (see .settings/docs/4817/STANAG-4817-FEDERATED-FUSION.md) Medusa is the per-site fusion shard: it turns many UXVs' STANAG 4817 tracks/contacts, seen under different IDs and affiliation labels, into a single lineage-tagged track on the COP. It fits the standard embed shape below once built, but unlike the others it is a first-party R2-D2 service rather than an externally owned app.

Why it depends on Imp Intel. Fusion is only as good as the inputs. Each UXV carries a bias and a variance that change with range; Imp Intel's passive calibration measures those against known references so Medusa can correct bias and weight by variance. No calibration, no trustworthy fusion.

Configuration

Each embed has a URL env var read at build time:

If a URL isn't configured, the corresponding sidebar item shows a Vader icon — the page is still navigable (you'll see a configuration placeholder) but the embed itself won't render.

Why iframes (not portlets)

Two reasons:

1. The apps have their own teams. They ship their own UIs on their own cadence. Trying to portlet them in would require maintaining a stable component contract across multiple repos; iframes give us a URL contract instead and stay out of their way.
2. Auth scope. Each embed has its own auth path (some federate with TrailBase, some don't). An iframe keeps the auth boundary clean — the embed sees its own cookie, the dashboard sees its own.

The cost is what iframes always cost: no in-page navigation interop, no deep links into the embed's internal state without help from the embed, and a slightly weird back-button story. We accept it.

Sidebar "The Force" tile

The sidebar shows an aggregate readiness tile: "Configured: 3/5" with a green/yellow/red dot. It's a quick "did someone forget to wire HOLONET_URL" check, nothing more. The readiness is configuration-only — it does not probe the embeds themselves (reachability is the embed's problem to surface inside its iframe).

Adding a new embed

1. Add the URL env var to src/lib/forceEmbeds.ts and export a *Configured boolean.
2. Create src/app/the-force/<name>/page.tsx mirroring holonet/page.tsx — same full-bleed iframe pattern.
3. Add the sidebar nav entry with an appropriate icon. Hook the downItems set in Sidebar.tsx so the Vader icon appears when the URL is missing.
4. Document the embed in this page.

Don't over-build the integration. If the embed needs more dashboard-side context than "here's a URL", that's a sign it belongs on its own plane, not on the Force.

Built on