docs(ML-93): answering machine detection for live STT - #139
Closed
jqueguiner wants to merge 3 commits into
Closed
Conversation
Documents the new answering_machine message: what it is, why it uses speech timing instead of the transcript, the payload, and how to act on it. - chapters/live-stt/features/answering-machine-detection.mdx : the feature page - api-reference/v2/live/callback/answering-machine.mdx : payload reference - asyncapi.yaml : AnsweringMachineMessage schema, channel message and operation - docs.json : both pages added to the navigation Two points made explicit for integrators, because both are easy to get wrong: confidence is a ranking score and not a calibrated probability, and silence is reported as human rather than machine. Refs ML-93
Contributor
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
jqueguiner
changed the title
This repo is public. The first version described how the detector works internally, which does not belong in customer documentation: - benchmark figures from our evaluation (accuracy percentages, CPU latency, training set size) - the named features the model relies on and their relative importances - the exact decision window length - the ablation result comparing timing against transcription - a link to the third-party post the approach draws on Kept what an integrator actually needs: the message shape, what each field means, that confidence is a ranking score rather than a probability, that silence is reported as human, and the limits. Also relevant for ML-93: the patent filing on the address resolver set the precedent that implementation detail stays internal until priority is established.
time is the position in the AUDIO stream, not wall clock. It matters because a client pushing audio faster than real time will see time: 5.24 arrive within a fraction of a second: created_at is the field to correlate with their own logs. Also fixes the examples, which showed time: 5.0 exactly and implied a fixed value. The decision is triggered by a speech segment crossing the window rather than by a timer, so the value sits a little past it. Adds a Note explaining that answering_machine shares its clock with speech_start, speech_end and transcript, which is what lets an integrator verify the decision arrives before the first transcript.
Contributor
Author
|
Superseded by #140, which carries the same four files in a single commit. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Documents the
answering_machinemessage for live STT.chapters/live-stt/features/answering-machine-detection.mdx— the feature pageapi-reference/v2/live/callback/answering-machine.mdx— payload reference, same shape as the existingspeech-start/speech-endpagesasyncapi.yaml—AnsweringMachineMessageschema with examples, theansweringMachinechannel message, theonAnsweringMachineoperationdocs.json— both pages in the navigationThe message
{ "session_id": "550e8400-e29b-41d4-a716-446655440000", "created_at": "2026-09-09T12:34:11Z", "type": "answering_machine", "data": { "kind": "machine", "confidence": 0.78, "time": 5.24, "channel": 0 } }Three things stated explicitly, because all three are easy to get wrong
confidenceis a ranking score, not a probability.0.78does not mean "78% chance of a machine". The page says so in a<Warning>and tells integrators to tune a threshold on their own traffic instead.Silence is reported as
human. A callee who never speaks produces no speech at all, and staying on the line beats hanging up on someone quiet.timeis the audio position, not wall clock. It shares its reference withspeech_start,speech_endandtranscript, so messages can be ordered against each other. A client pushing audio faster than real time will seetime: 5.24arrive within a fraction of a second, socreated_atis the field to correlate with their own logs.All three would otherwise surface as support tickets.
Verified
asyncapi.yamlparses and the new nodes resolve on theliveTranscriptionchannel.docs.jsonis valid JSON with both entries in the navigation. Mintlify validation and link-rot checks pass on the branch.Refs ML-93