Value this issue delivers
A customer whose policy says "Amazon Transcribe for all audio processing" can run the transcription brick with Transcribe as the engine and change nothing else: the bot's whisper client keeps posting 16 kHz WAV windows to POST /v1/audio/transcriptions and keeps receiving the same verbose_json shape. Today the brick is faster-whisper only, and Transcribe's streaming API speaks HTTP/2 event streams with SigV4, which the bot must never learn.
What this issue ships
STT_BACKEND=whisper|transcribe on core/meetings/services/transcription, default whisper, behaviour unchanged when unset.- With
transcribe: no Whisper model is loaded; each request's WAV window is sent through Transcribe streaming (amazon-transcribe, Apache-2.0) with the AWS credential chain and AWS_REGION; final results are mapped into the existing segment shape; language codes map from the bot's ISO-639-1 to a BCP-47 default with TRANSCRIBE_LANGUAGE_DEFAULT.
- Errors keep the contract the bot already handles: throttling →
503 with Retry-After; malformed audio → 422; missing credentials → 503 and /health says why.
- A compose file under
deploy/transcription/ for the Transcribe-backed unit and a docs section on the custom-STT how-to.
Validation contract
Machine-observable, offline: the existing suite stays green with the default backend; new tests drive the endpoint with a stubbed streaming client and assert the response keys are identical to the whisper path, the three error mappings, and both /health states. A live run against a real Transcribe account is verified by the caller and reported here.
Out of scope: Transcribe batch jobs (S3 round trip, seconds of latency per window); speaker labels from Transcribe (per-participant audio already gives identity); any change to the bot.
Refs: business custody DmitriyG228/biz#208.
Value this issue delivers
A customer whose policy says "Amazon Transcribe for all audio processing" can run the transcription brick with Transcribe as the engine and change nothing else: the bot's whisper client keeps posting 16 kHz WAV windows to
POST /v1/audio/transcriptionsand keeps receiving the sameverbose_jsonshape. Today the brick is faster-whisper only, and Transcribe's streaming API speaks HTTP/2 event streams with SigV4, which the bot must never learn.What this issue ships
STT_BACKEND=whisper|transcribeoncore/meetings/services/transcription, defaultwhisper, behaviour unchanged when unset.transcribe: no Whisper model is loaded; each request's WAV window is sent through Transcribe streaming (amazon-transcribe, Apache-2.0) with the AWS credential chain andAWS_REGION; final results are mapped into the existing segment shape; language codes map from the bot's ISO-639-1 to a BCP-47 default withTRANSCRIBE_LANGUAGE_DEFAULT.503withRetry-After; malformed audio →422; missing credentials →503and/healthsays why.deploy/transcription/for the Transcribe-backed unit and a docs section on the custom-STT how-to.Validation contract
Machine-observable, offline: the existing suite stays green with the default backend; new tests drive the endpoint with a stubbed streaming client and assert the response keys are identical to the whisper path, the three error mappings, and both
/healthstates. A live run against a real Transcribe account is verified by the caller and reported here.Out of scope: Transcribe batch jobs (S3 round trip, seconds of latency per window); speaker labels from Transcribe (per-participant audio already gives identity); any change to the bot.
Refs: business custody DmitriyG228/biz#208.