MODELS AND MODALITIES

Live and recorded transcription are different contracts

Event source: Gemini 3.5 Transcribe adds intelligent transcription paths ↗

In this analysis
THE RETROSPECTIVE TAKE

Useful live text can precede a completed transcript, while recorded processing needs an explicit association with its bounded input.

Two paths served different temporal needs

Gemini 3.5 arrived on May 19, 2026, followed by Live Translate on June 9. The August 26 Transcribe launch separated real-time streaming from recorded-audio processing. These paths address different temporal conditions. A live application needs useful text before all audio exists, while a recording workflow can examine an already bounded input. Treating them as the same operation with different delivery speed conceals important questions about provisional display, completion and the evidence available at each moment.

A live display needs revision semantics

An illustrative captioning application shows a sentence while the speaker is still talking. Later speech can clarify an earlier ambiguous word or reveal a correction. The application should know which displayed material is tentative and which has reached the supported completion boundary of its actual API. That boundary must come from the documented event contract, not an invented field name. The design issue is general: text that is useful for immediate reading may not yet be the right artifact for indexing, quoting or triggering a downstream action.

Recorded work begins with an input boundary

A recording pipeline can identify the file or segment that was submitted and associate the resulting transcript with that input. This helps reproducibility, but it does not guarantee perfect recognition. It also introduces its own failure modes, such as processing the wrong version or omitting the end of a file. A useful acceptance record preserves the submitted input identity and the completion state. The distinction from live work concerns the timing of available evidence, not an assumption that offline text is automatically authoritative.

An illustrative end-of-input fixture

A practical test contains a spoken correction near the end of an audio segment. The live case inspects what a reader sees before and after the correction; the recorded case checks the transcript associated with the completed segment. The review also verifies that a premature connection closure is not treated as proof that the entire intended input was processed. No latency number or recognition score is claimed. The fixture exposes temporal mistakes separately from the question of whether the final words were recognized correctly.

Choose the contract before the integration shortcut

The August release makes both interactive and post-recording applications plausible. A shared model family does not remove their different state obligations. The retrospective lesson is to define when text becomes usable for each downstream purpose and what evidence establishes completion. A caption can be useful before it is final; an archival transcript needs a stronger input association. Keeping those roles explicit prevents a convenient streaming integration from silently becoming an unsupported record-processing guarantee.

← All retrospectives