Skip to main content

Overview

All heavy processing (transcription, summarisation, HiRAG indexing) happens asynchronously. The API never blocks waiting for these — it accepts the upload, creates a job record, pushes to Redis, and returns immediately. Workers process jobs in the background.

The pipeline

Job types

The five queues

Pub/sub channels are separate from the queues: kair:chunk_transcribed, kair:job_status_changed, kair:moderator_insight.

HiRAG indexing phases

Chunk vs final transcription

Sessions are recorded in chunks (short audio segments sent as the recording progresses). Each chunk gets its own transcription job immediately — this gives live feedback in the moderator view. When the session ends, all chunks are stitched into one audio file. A final transcription job runs on the full audio. This final transcript is what gets summarised and indexed — chunk transcripts are for live display only.
The final transcription is also where speaker diarisation runs (when enabled). Chunks are never diarised individually — only the full stitched audio.

Job states

Failed jobs are visible in the admin panel. Individual failed chunks can be re-run from the admin UI. If the final transcription fails, summarisation and HiRAG indexing do not run.

Transcription backends

Two backends are supported, switchable at runtime via the admin panel: Switching backend takes effect per-job — no worker restart needed (except switching back to local on a Foresight-booted worker, which requires a restart to load the Whisper model).
Foresight rejects audio uploads larger than 200 MiB. Very long sessions should always use chunked upload rather than a single-file upload.

Monitoring

  • Admin panel → Jobs: shows all transcription jobs, chunk groups, status, and progress
  • Failed jobs: visible in admin with a “re-run” action per chunk
  • Logs: worker processes log job pickup and completion with session/job IDs