Core concepts

How Toluva works

Six stages. Each one reads from storage, writes what it did, and hands off. Nothing is held only in memory, and nothing is overwritten.

The six stages

1

Ingest

The source clip and an immutable job request are written to B2. The request carries the target language, the purpose, the client-reported duration, the admission slot, and both required confirmations.

2

Transcribe

Faster Whisper produces timed segments. Confidence and trailing-fragment checks run here; a weak transcript blocks before translation rather than after speech has been paid for.

3

Translate

Argos Translate produces the target text per segment with protected terms preserved. Translation records are written before and after each stage.

4

Authorize

The requested language and purpose are evaluated against the stored authorization record. This is the last point before spend.

5

Time-fit QA

Speech is generated per segment, then measured. Drift decides whether the segment is accepted, padded, tempo-fitted, or blocked for revision.

6

Master

Source-timed audio fan-in, caption generation, and a three-input video composition produce the final render.

Why the order matters

The expensive call is speech generation. Every gate that can fail is placed before it:

  • A clip outside the duration or size limits never uploads.
  • A transcript below confidence blocks before translation.
  • A language or purpose outside the authorization scope is refused before the provider is contacted.

Fail closed, fail early

Each of those refusals is itself recorded. A blocked run is not an absence of evidence — it is evidence that the boundary held.

What is measured, not assumed

Duration is read from the generated audio file, never estimated from character count. That distinction is the whole basis of timing QA: a translation that looks short can still overrun its slot, and only measurement catches it.

Stored media hashes are re-checked before the application describes bytes as verified. A manifest that claims a hash is not sufficient on its own.

Failure behaviour

FailureBehaviour
B2 read unavailableThe stored snapshot stays visible; the app says so
Worker offlineJobs queue durably; no provider is called
Provider call failsRecorded as a failed attempt, kept in the audit trail
Segment outside bandBlocks and waits for an approved revision
Job pointer expiredCleared from the browser; the B2 record is unaffected

The interface is built to say what is actually true about the current state rather than to look healthy.

Next