Training sessions

A live training session is brokered by the session-gateway. The browser holds one WebSocket to MTP and never connects to HOPE’s data plane directly. Microphone audio flows up that socket; LLM text fragments, speech audio, and facial blendshape frames flow back down.

Why a broker, not a direct embed

HOPE documents a direct browser-to-HOPE embed pattern. MTP deliberately does not use it, for four reasons:

Ground-truth secrecy. The run envelope’s scenario_fields carries which persona fields are deceptive. Composed in the browser, that would be one dev-tools inspection away from the trainee. The gateway composes run envelopes server-side from a stated-fields-only view — actual values are structurally absent from anything sent to HOPE or the browser.
Authoritative transcripts. HOPE exposes no transcript read API, so scoring integrity requires a transcript recorder the trainee cannot tamper with. The gateway records both directions of every exchange with an individually addressable exchange_index that assessment and coaching reference later.
Flow enforcement. Phase gates, trainer overrides, and termination rules run server-side where they cannot be bypassed. Session state is server-side from day one and resumable at phase boundaries from any workstation.
Rate-limit stewardship. HOPE budgets agent-stream connections per credential. The gateway paces turns, pools per-tenant credentials, and backs off centrally instead of in every browser.

The cost is trivial: 16 kHz mono PCM upstream is about 32 KB/s, and in-cluster relay adds single-digit milliseconds against a sub-3-second voice-latency budget.

What flows where

Leg	Content	Credential
Browser → gateway	Mic PCM, flow actions	`mtp_access` session cookie
Gateway → HOPE `/stt`	Relayed PCM	Machine token (per-tenant API key)
Gateway → HOPE `/agent-stream`	Run envelope: metahuman id, archetype id, stated fields only	Machine token (per-tenant API key)
HOPE → gateway → browser	LLM fragments, PCM audio, blendshape frames	—
Gateway → Postgres	Both speakers’ turns, exchange-indexed; flow state transitions	—

Avatars

Standard 3D avatars render in the browser with HOPE’s renderer, fed by gateway-relayed blendshape and PCM frames.
Premium avatars are the one exception to strict brokering: the gateway creates the live-avatar session with its machine token, but the returned subscribe-only LiveKit token goes to the browser, which attaches media directly. Video never carries ground truth, and relaying WebRTC would be pure loss. On live-avatar runs the gateway suppresses its local audio relay.

Session identity and tenancy

Each MTP training session mints an unguessable conv-<uuid> as the session identifier sent to HOPE.
Users are identified to HOPE only by an opaque surrogate (usr_<uuid>), never by email. The surrogate drives HOPE’s repeat-offender guardrail escalation and appears in webhook payloads.
Each MTP tenant is a separate HOPE organization with its own API keys, so guardrail policies, entitlements, and usage metering are isolated per customer.

After the session

When the flow reaches its scored state, the api service enqueues an assessment job. The assessment engine makes one post-session inference pass — transcript, rubric, and scenario ground truth in; a unified assessment payload out — and that stored payload is the single source of truth for the debrief, dashboards, exports, and LTI grade passback. The coaching debrief renders entirely from the stored payload with zero LLM calls at render time. See The content kernel for how rubrics and coaching templates define this pipeline.

Guardrail events arrive from HOPE as HMAC-signed webhooks. A guardrail.session_terminated event marks the MTP session as terminated by guardrail and surfaces it in trainer and program-administrator views.