> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Video live interpretation model > How Orbit renders real-time spoken-language interpretation inside a video room — the per-language LiveKit audio track, the utterance-to-TTS request flow, the closed language whitelist, the same-language short-circuit, and the length-only privacy posture # Video live interpretation model Live interpretation is the **spoken interpreter channel** for a video room: a per-language audio track a participant listens to while a speaker is interpreted aloud into their language — the audio analog of the translated caption line. This page is the model behind `POST /api/v1/video/interpretation`. The room itself is covered in [The video room model](/concepts/video-room-model); here we cover the interpretation surface. ## What live interpretation is — and what it is not Two video translation surfaces exist, and they are easy to conflate: | | Live interpretation (`/video/interpretation`) | Broadcast captions translation (`/video/captions/translate`) | | -------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | Output channel | Spoken audio onto a per-language interpretation track (Zoom "Language Interpretation" / Teams interpreter parity) | On-screen text rendered as a translated caption line | | Consumer | A participant listening to the interpretation channel | A viewer reading the caption overlay | | Rendering | The client hands the returned line to TTS and plays it on the interpretation audio track | The client draws the returned text on the caption overlay | Live interpretation handles exactly two things per call: it interprets one finalized caption/STT utterance from the speaker's language into the channel's language, and it returns the spoken-ready line. It does **not** place calls, send messages, or wire any outbound media — the only network hop is one text machine-translation call (see the scope note at the end). ## Topology: one interpretation audio track per language Each interpretation channel is a dedicated LiveKit audio track inside the room the participant has already joined. The speaker's own microphone track is untouched; the interpreter channel is an *additional* audio track that carries the interpreted speech. A participant chooses which channel — and therefore which `target_language` — they listen to, and the room can carry several channels at once (one per supported language in use). Because the track lives inside the LiveKit room, listeners need no extra connection; a client joins the room and publishes/subscribes to the interpretation track with the same join-token flow the room model page describes. ## Request flow: utterance → interpret → TTS handoff One interpreted line moves through six steps: 1. **Finalized utterance** — the caption/STT pipeline (browser → Deepgram → LiveKit data channel) emits a final caption segment. Interpretation runs on *finalized* segments only, so partials never reach the server. 2. **POST `/video/interpretation`** — the speaker's client posts the utterance text, `source_language` (the speaker's caption language), and `target_language` (the interpretation channel's language). An optional `speaker_name` label may accompany them for display attribution. 3. **Validate** — the body is validated against a strict schema. Language values outside the whitelist are rejected with a `400 INVALID_LANGUAGE` (see below); any other validation failure is `400 INVALID_REQUEST`. 4. **Direction resolution** — the server decides whether interpretation is needed. When `source_language` equals `target_language`, it returns immediately with `interpreted: false` and echoes the original text — no LLM call is made (see the short-circuit below). 5. **Interpret** — the utterance goes through the platform's LLM-spend plumbing, using the configured fast model and a spoken-language prompt (numbers, URLs, and names kept verbatim; nothing added or omitted). The spend is metered to your tenant wallet and passes the same daily-cap. and rate gates as every other AI translation surface. 6. **TTS handoff** — the response carries `interpreted: true` plus `translated_text` and the model id. Your client hands `translated_text` to text-to-speech and publishes the audio onto the interpretation channel's LiveKit track. `speaker_name` is echoed back so the client can attribute the line on the channel (for example, "\[interpreting Amira]"). The endpoint is **stateless**: no database row is read or written on the hot path. Video rooms have no live session row during the meeting — the durable transcript lands only after egress via the post-meeting transcript pipeline — so interpretation deliberately persists nothing; the durable post-meeting record is owned by the existing transcript/summary pipeline. ## Language whitelist and the 400-on-unsupported contract Both `source_language` and `target_language` are closed enums — the same whitelist the broadcast-captions translation surface uses, so the two translation surfaces can never drift to different supported sets: ``` en, es, fr, de, hi, it, ja, ko, nl, pt, ru, sv, tr, zh ``` A request whose only problem is an unsupported language gets back `400` with `error.code: INVALID_LANGUAGE` and a message listing the supported set; any other body-validation failure gets `400 INVALID_REQUEST`. This closed whitelist exists on purpose: it keeps the billable LLM-spend surface auditable, and it rejects a wrong value loudly instead of spending on it. Deepgram's code-switching `multi` transcription sentinel is deliberately excluded — it is a valid transcription *input* mode, not a real language you can interpret into. ## Same-language short-circuit before any LLM spend When the speaker already speaks the channel's language (`source_language == target_language`), the server never calls the model. It responds `interpreted: false` with the original text echoed in both `source_text` and `translated_text` and `model: null`, so your client can pass the original audio straight through — and no interpretation charge accrued. Check `interpreted` on every response: when it is `false`, skip TTS and leave the speaker's own audio untouched. ## Authentication, scopes, and rate limits The endpoint sits under the same auth envelope as every video route: * Any valid API key needs `video:read` or `video:write` to reach it. * The interpret verb itself layers `video:write` plus the `owner`, `admin`, or `developer` role — a read-only key can discover the surface (and see 403/503 envelopes) but cannot burn billable LLM spend. * The endpoint is rate-limited under the authenticated-write bucket, the same budget other mutating video routes share. ## Privacy posture: length-only logging Spoken content in a meeting can carry PII, so the interpretation surface deliberately records as little as possible. The audit event written per interpretation stores the source and target language, the model id, and the **source text length only** — never the utterance text itself, and `speaker_name` is never audited. That is enough for your SOC team to reconcile an LLM-spend spike to interpretation volume without retaining meeting content. The interpret service and its log hold the same posture: no utterance text is persisted anywhere on this surface. ## Audit and deletion notes Each interpretation emits one `video_room.interpreted` audit event (resource `video_interpretation`) carrying the language pair, the model id, and the source character count. Because interpretation is stateless, there is no per-line interpretation record to delete: retention and deletion of actual meeting content belong to the post-meeting transcript and summary pipeline, which owns the durable record. Deleting a room's session or transcripts through the normal retention sweep removes the meeting record without touching interpretation audit entries, which were always content-free. ## Scope note: no outbound media leg Live interpretation is text machine-translation only. It places no call, sends no message, and wires no outbound media provider; the interpreted audio is rendered client-side onto a LiveKit track inside the room the participant already joined. Orbit routes all outbound call and message termination through its own softswitch — the interpretation surface touches none of that by design. ## Related The room lifecycle, join tokens, recording and broadcast, analytics, QA scoring — the surface interpretation runs inside. How in-room bot participants are dispatched — the queue that carries a persona into the same LiveKit room model. How Orbit gates video publishing in audio-only rooms. The endpoint-by-endpoint contract this model is implemented by.