Downstream (Content Delivery)

Deliver content to the field — ExperienceLibrary stores experiences, HydraHead serves them, HydraBody renders them.

What You'll Have

After completing the downstream phases, the pipeline has:

• A promoted experience — the staging (or production) build is live in ExperienceLibrary
• Provisioned render nodes (bodies) — running the new build, streaming via LarkXR
• Connected interface devices (heads) — kiosks, tablets, or VR headsets presenting the stream to end users

HydraExperienceLibrary                 HydraCluster
┌───────────────────────────┐         ┌─────────────────────────────┐
│ visit-flanders-main-exp   │         │ bxl1 / heysel               │
│   staging: build 1 v1.0.0 │────────→│   body-001 ● running v1.0.0 │
│   district: bxl1          │ trigger │   body-002 ● running v1.0.0 │
│   venues: heysel, ad6     │ reprov. │   head-001 ● streaming      │
└───────────────────────────┘         └─────────────────────────────┘

End users interact with heads. Heads connect to bodies over the network managed by HydraNeck. Bodies run the build from HydraRelease.

Phase 4: Promote Experience

Components: HydraExperienceLibrary Type: Sequential (follows Phase 3 — upstream promote)

The experience already exists (created during foundation setup). When a new build arrives, ExperienceLibrary picks it up and you promote it through environments.

ExperienceLibrary subscribes to HydraRelease's SSE stream and reacts to build.uploaded events. When a new build appears for a project it tracks, it automatically updates the experience's development build. If auto_promote is enabled, promotion happens automatically. Otherwise, promote manually:

hydraexperiencelibrary promote visit-flanders-main-experience --to staging

What to Verify

hydraexperiencelibrary get visit-flanders-main-experience --json
hydraexperiencelibrary status

SSE events emitted: experience.promoted

Active components: HydraExperienceLibrary

Phase 5: Provision Nodes

Components: HydraExperienceLibrary → HydraCluster → hydrabody agents Type: Two sequential waves, each internally parallel

When the experience library promotes and targets districts/venues, it triggers reprovisioning in two waves: bodies first, then heads. Bodies must be running the new build before heads reconnect to their streams.

ExperienceLibrary
    │
    ├── GET /api/v1/nodes?district=bxl1&venue=heysel  (HydraCluster)
    │   → returns: [body-001 (render-node), body-002 (render-node), head-001 (head), ...]
    │
    │  Wave 1: Bodies (parallel)
    ├── POST /api/v1/nodes/body-001/reprovision        (HydraCluster)
    ├── POST /api/v1/nodes/body-002/reprovision        (HydraCluster)  ← parallel
    │
    │  Wave 2: Heads (parallel, after bodies complete)
    ├── POST /api/v1/nodes/head-001/reprovision        (HydraCluster)
    └── ...

Wave 1 — Bodies (render nodes)

1. Detect reprovision: true flag in next heartbeat response
2. Download the build artifacts from HydraRelease (or the district mirror)
3. Configure the streaming provider (LarkXR)
4. Report success/failure back to HydraCluster via POST /api/v1/body/provision-result

Wave 2 — Heads (interface devices)

1. Detect reprovision: true flag in next heartbeat
2. Receive updated stream configuration (new app ID, stream URL)
3. Reconnect to the body's stream — no build download needed
4. Report success/failure back to HydraCluster

Bodies and heads within each wave reprovision in parallel. The two waves are sequential: heads wait for bodies.

What to Verify

# Check node status in HydraCluster dashboard
# Nodes should show provisioning → online

# Health endpoint shows fleet state
curl https://hydracluster.experiencenet.com/api/v1/health

SSE events emitted: provision.started, provision.completed (or provision.failed) per node

Active components:

• HydraExperienceLibrary (triggers reprovision)
• HydraCluster (sets flags, serves config)
• hydrabody agents on each node (download, provision)
• HydraRelease (serves build artifacts)
• HydraNeck (ensures bodies and heads are on the same network)
• Streaming provider / LarkXR (configuration)

Promoting to Production

Once staging is validated, the same flow repeats for production:

# Promote the same build to prod in HydraRelease
hydrarelease release promote \
  --project visit-flanders-main-experience \
  --env prod --build 1 --version "1.0.0" \
  --server https://releases.experiencenet.com \
  --token $HYDRARELEASE_AUTH_TOKEN

# Promote in ExperienceLibrary
hydraexperiencelibrary promote visit-flanders-main-experience --to production

Production promotion triggers reprovisioning of production nodes. Staging nodes are unaffected.

Observability

Throughout all phases, HydraPipeline observes:

# Health of all services
hydrapipeline status

# Live event stream (shows build.uploaded, release.promoted, provision events)
hydrapipeline watch

HydraPipeline is purely read-only — it never triggers or modifies anything. It consumes SSE events from all hydramonitor-enabled services to provide a unified view.