End-of-turn detection for lists, spelled names, and unfinished sentences

TL;DR: End-of-turn detection needs the shape of the requested answer as well as evidence of silence. Keep lists, spelling sequences, and unfinished clauses open until their completion contract is satisfied or clarification is required, then evaluate premature cutoff and excess waiting against the same labeled corpus.

---

The caller starts spelling a surname, pauses to find a letter, and hears the agent read back the unfinished name. The recognizer may have produced a valid final segment, yet the application closed the answer before the caller finished it.

A list produces the same failure through different evidence. "I need a charger, a cable, and..." contains several plausible completed items but an unfinished request. Acting on the collected items immediately can create a partial order that the caller never intended.

Treat endpointing as a decision about an answer boundary. This guide gives you a continuation-cue corpus, an executable evaluation artifact, and a release method that keeps acoustic segmentation separate from field validation and authorization.

All sample utterances and timing fixtures are synthetic. The figures explain concepts rather than measured performance. Public API documentation was reviewed on November 9, 2026; no production result or private implementation of 60db Agent is described.

Table of contents

1. Define the answer completion contract
2. Identify structured continuation cues
3. Separate recognizer and dialogue boundaries
4. Design an endpoint state machine
5. Run a boundary evaluator
6. Build a corpus that exposes cutoff
7. Choose a policy with paired replay
8. Handle deployment failure cases
9. Frequently asked questions
10. Validate the next boundary

Define the answer completion contract

An answer completion contract describes what makes the requested input usable. It includes the expected structure, any explicit completion signal, validation requirements, and what the application should do when the caller stops before satisfying those requirements.

For a surname, completion might require a complete spoken name or a spelling sequence followed by read-back. For a list, it might require an explicit "that's all" or a task-specific clarification. A free-form explanation may need only a conversational completion judgment.

These contracts should remain visible to the endpoint controller. A universal silence duration cannot know whether a pause occurs between list items, between letters, or after the answer. The same acoustic gap can demand different application behavior.

Start by naming the pending input. delivery_items, surname_spelling, and problem_description have different completion rules, even when they share the same recognizer and audio transport.

The VAD and turn-detection guide explains the foundational distinction. Here the next separation matters: conversational turn completion and field validity are also different facts.

A caller can finish saying an invalid code. A caller can pause after saying a valid-looking prefix of a longer identifier. A parser accepting the current buffer does not prove that the caller has finished, and an endpoint does not prove that the parsed value is correct.

Define the safe consequence of each boundary. Closing an answer may allow validation and a read-back; it should not directly authorize a purchase or commit an appointment. That later boundary belongs to the workflow enforcement contract.

Scope the question before collecting input

Question design changes endpoint ambiguity. "What do you need?" invites a list with no visible end; "Tell me each item, then say 'that's all'" gives the caller an explicit completion mechanism.

Use explicit completion when it reduces genuine ambiguity, and still support callers who do not follow the phrasing. If the caller pauses without the requested signal, ask a concise clarification instead of assuming either completion or failure.

For spelling, say how the sequence will be confirmed. A caller who knows the agent will read it back can correct a mistaken letter without restarting the entire exchange, provided the application preserves the sequence as structured text.

Keep question identity with the input buffer. If the agent asks a new question while a delayed transcript from the previous one arrives, that result must remain attached to its original answer scope.

Identify structured continuation cues

Continuation cues are evidence that the current answer remains open. They include unfinished syntax, a list coordinator without its next item, an announced count that is not yet satisfied, and an explicit request to wait.

Each cue needs context. "And" at the end of a partial transcript may be revised away; "that's all" may occur inside quoted material; "two" can be a quantity rather than an item count. Treat these observations as features attached to a question rather than global command words.

The OpenAI VAD guide documents a semantic mode that considers whether an utterance is complete, alongside a silence-based mode. That public distinction supports evaluating semantic completion separately, while leaving your task's structured completion rules under application control.

Avoid presenting semantic endpointing as a universal solution. A complete sentence can still be one item in an unfinished list, and a spelling sequence may lack the syntax that a sentence-completion model expects.

An open list or spelling sequence returns to listening. A complete answer proceeds to field validation. The figure describes application decisions; it does not imply that an acoustic or language model can infer every branch without uncertainty.

Use a criteria table to review candidate evidence. ✓ means the cue can support the stated decision in the example contract; ✗ means it cannot establish that decision alone. Conditional entries require the pending question's structure and validation rules.

The timeout row is deliberate. Expiry is evidence that your waiting budget ended; it is not evidence that the caller's intended value is complete. The controller can move to clarification without pretending the answer was complete.

Lists need an end rule

A variable-length list has no intrinsic terminal item. If the application accepts items as they arrive, keep them provisional until an explicit end condition or clarification closes the collection.

Preserve order only where it matters. A sequence of installation steps differs from a set of requested accessories; deduplicating repeated items can be correct for one task and destructive for another.

An announced count provides a useful consistency check but remains revisable. "I need three things" followed by four items may reflect a changed mind rather than a recognition failure. Ask about the mismatch instead of dropping the extra item or inventing a missing one.

A pause after an item should not restart collection. Keep the accumulated list and the open boundary, then let the caller continue. If a no-input policy intervenes, it should ask whether the list is complete without discarding the accepted provisional items.

Spelling needs sequence ownership

Store spelling as a sequence of characters or explicitly interpreted tokens. Preserve leading zeros and distinctions between a spoken letter, its phonetic clarification, and an entire word offered as an example.

"B as in Bravo" contributes one intended letter under a typical spelling contract. Treating every recognized word as literal characters will corrupt the value, so the normalization adapter needs its own tests and an uncertainty path.

A caller may repair the sequence: "M, A, no, E." That is a revision to the current position or prefix, not always an append operation. The spoken self-correction ledger provides a separate contract for that problem.

Avoid solving repair by extending silence forever. Endpointing controls when to consider the answer complete; revision logic controls which characters survive. Both must be right before read-back.

Unfinished clauses need task context

A clause ending in "because," "unless," or "but" often requests more listening time. Yet a caller can stop mid-thought and choose not to continue, so the controller still needs a bounded clarification route.

Do not require grammatical completeness as a universal condition. "Tomorrow afternoon" is a complete answer to a scheduling question, while a fully grammatical "I have another item" leaves a list incomplete.

Use the prior question as part of the evaluation fixture. Testing isolated utterances hides the information that makes these examples distinguishable and can lead you to blame a classifier for an impossible inference problem.

Separate recognizer and dialogue boundaries

A streaming recognizer may finalize several segments during one user answer. Concatenating those segments into an answer is an application job, and closing the recognizer stream is a separate transport decision.

Google's streaming recognition reference defines isFinal for a specific result and describes interim stability separately. Those definitions do not make a finalized segment a completed list, spelling sequence, or caller intent.

Preserve result identity and audio offsets when the provider supplies them. Otherwise a revised interim result may be appended as a new segment, producing duplicate letters or list items that the caller never said.

The Google streaming request overview distinguishes interim hypotheses from final recognition results. Keep that distinction in the adapter instead of converting every text callback into an append-only message.

For realtime speech-to-speech systems, the transcription can be asynchronous to response generation. OpenAI's server events describe that timing and warn that the transcript is a rough guide to the audio-native model's interpretation.

This means an application that waits for transcript-based continuation evidence needs an explicit scheduling policy. If automatic response creation already started, the application must decide whether to pause, cancel, or replace that response when later evidence shows the answer remained open.

Keep automatic actions under one owner

Inspect which component closes the turn. A speech provider, media framework, and application may all include endpointing settings, and stacking them without understanding their relationship can add waiting or produce contradictory actions.

The OpenAI client-event reference exposes separate automatic response and interruption controls. Use the exact current schema for your integration, and test the resulting events rather than assuming one provider's configuration shape applies elsewhere.

Document the effective policy in the release packet. Record the recognizer model, endpoint mode, application hold rule, and timeout owner; a list of values without their ownership cannot explain why the agent responded early.

The partial-transcript revision guide covers the input gate in more detail. Endpointing should consume stable evidence about the answer while preserving the fact that later caller speech can revise the task.

Conceptual: A final recognition result, a completed answer, and a valid field remain separate evidence.

Design an endpoint state machine

Use explicit states such as collecting, candidate_complete, clarify, and closed. A silence event can move collection to a candidate boundary; structure and semantic evidence determine whether that candidate can close.

An open structure returns to collection until its waiting budget expires. Budget expiry moves to clarification. A valid completion signal moves to field validation, and validation either accepts the provisional answer or asks a targeted repair question.

Keep closure idempotent. Duplicate provider stop events should not produce two read-backs, and a delayed candidate-complete result must not reopen an answer already replaced by a newer question.

The state machine needs an answer epoch or equivalent identity. Increment it whenever the application abandons the current input scope, starts a new question, or resets collection; reject callbacks tied to earlier epochs.

A hold should preserve accumulated evidence. It should not make the recognizer stop receiving audio or clear characters just because the application chose to wait before responding.

Bound waiting without assuming completion

A maximum wait protects the caller and the service from an endless open state. At that boundary, ask a question that resolves the uncertainty, such as whether there are more items or whether the spelling is complete.

Avoid a generic "I didn't understand" when you already have part of the answer. A targeted clarification acknowledges the collected information and asks only about the missing boundary.

The progressive no-input guide develops the silence ladder. It separates a caller thinking, an unavailable input path, and an explicit wait request so that timeouts do not erase useful state.

A caller who says "one moment" should not trigger the same timer behavior as a caller who has never produced input. That statement is new information about expected continuation, even though it does not complete the requested field.

Make field validation a separate transition

Once the endpoint closes, validate the entire collected answer. Check list constraints, spelling uncertainty, required fields, and any task-specific normalization before presenting a read-back.

Do not use validation success to retroactively justify an early endpoint. A prefix can pass a validator while being the wrong intended value; this is common with variable-length names and identifiers.

If the caller corrects the read-back, reopen the relevant input scope and invalidate any confirmation tied to the previous value. The qualified-confirmation repair guide explains why "yes, but" needs to keep the action pending.

Conceptual: Syntactic validity does not close an open list, spelling sequence, or unfinished clause.

Run a boundary evaluator

The following evaluator compares proposed application endpoints with labeled completion boundaries. It uses integer ticks on one synthetic clock to avoid mixing wall time, audio offsets, and server timestamps.

Save the program as endpoint_eval.py and run python3 endpoint_eval.py. The fixtures and policy budgets are synthetic test inputs, not measured human pause distributions or recommended production timeout values.

from dataclasses import dataclass

@dataclass(frozen=True)
class Case:
    name: str
    reference_end: int | None
    candidate_end: int | None
    structure_open: bool
    explicit_done: bool = False

def classify(c: Case) -> str:
    if c.reference_end is None:
        return "unresolved" if c.candidate_end is None else "unsupported_close"
    if c.candidate_end is None:
        return "no_endpoint"
    if c.candidate_end < c.reference_end:
        return "early"
    if c.candidate_end == c.reference_end:
        return "aligned"
    return "late"

def permit_close(c: Case, budget_expired: bool = False) -> str:
    if c.structure_open and not c.explicit_done:
        return "clarify" if budget_expired else "listen"
    if c.candidate_end is None:
        return "clarify" if budget_expired else "listen"
    return "validate"

if __name__ == "__main__":
    cases = [
        Case("list continues", 90, 60, True),
        Case("spelling complete", 70, 70, False, True),
        Case("unfinished clause", None, None, True),
        Case("delayed response", 50, 80, False),
        Case("invented completion", None, 30, True),
    ]
    assert [classify(c) for c in cases] == [
        "early", "aligned", "unresolved", "late", "unsupported_close"
    ]
    assert permit_close(cases[0]) == "listen"
    assert permit_close(cases[0], True) == "clarify"
    assert permit_close(cases[1]) == "validate"
    assert permit_close(cases[2], True) == "clarify"
    assert permit_close(cases[4]) == "listen"
    delays = [c.candidate_end - c.reference_end for c in cases
              if c.reference_end is not None and c.candidate_end is not None
              and c.candidate_end >= c.reference_end]
    assert delays == [0, 30]
    print("Synthetic boundary checks passed")

The evaluator keeps early endpoints out of the nonnegative waiting-delay sample. Reporting a negative delay as an improvement would reward the policy for interrupting an unfinished answer.

unsupported_close is separate from early because the fixture has no labeled completion at all. A caller who trails off and never finishes needs a clarification outcome, not an invented reference boundary chosen to make the report computable.

The small permit_close function is a contract exercise. A production controller needs an event adapter, current answer identity, and explicit cancellation handling; the example isolates structure and budget behavior so those rules can be tested without a speech service.

Report the evaluator honestly

A passing assertion proves that this deterministic code matches its synthetic expectations. It does not establish a semantic detector's accuracy or demonstrate that the chosen timing policy fits real callers.

When you add actual measurements, keep the reference boundary definition with the dataset. Annotators may label the last acoustic speech sample, the end of a meaningful answer, or the point where a listener would respond; those choices produce different delay values.

Use the voice latency benchmark method to define the clock and observation point. Endpoint delay is only one part of caller-perceived response latency, and reducing it does not automatically improve task success.

The figure separates reference and candidate boundaries before classifying the outcome. An unresolved comparison remains unresolved; early cutoff and late response are distinct review categories rather than opposite signs of one quality score.

Build a corpus that exposes cutoff

Organize fixtures by the input contract. A spelling fixture should preserve character sequence and repair intent; a list fixture should preserve item boundaries and completion status; an unfinished-clause fixture should preserve whether a safe answer can be inferred at all.

Use paired variants that change one relevant cue. Compare "a cable" with "a cable and..." under the same question; compare a completed spelling sequence with the same sequence followed by a correction; compare a silence gap with and without an explicit wait request.

Include empty and failed-input cases. No recognized text can mean silence, poor capture, unsupported speech, or recognizer failure. It should not automatically become the same application event in every case.

Google's speech overview documents that unrecognized audio can yield no result items and identifies configuration or audio-quality causes. Use those possibilities to keep a no-result adapter from silently declaring that the caller had nothing to say.

Annotators should see the question and enough preceding output to understand the task. They should also know the label definitions, including when to mark unresolved rather than inventing a completed answer.

Keep a separate field for the online evidence cutoff. A retrospective reviewer can listen to the whole recording, while a streaming policy only had a prefix at the instant it acted. That difference helps locate premature action in the scheduling layer.

Add event-order fixtures

Recognition events can arrive after an acoustic endpoint, and provider callbacks can be duplicated. Replay candidate endpoint, transcript revision, structure update, and timeout in different orders while preserving any ordering the provider guarantees.

Assert that the same final evidence yields the same accepted field when no business action has occurred. If the application has already spoken or committed, record the visible difference rather than pretending that eventual state equality erased the user-facing error.

A late completion result from an old answer must not close the new question. Add a test in which the caller changes intent, the controller increments the answer epoch, and the previous detector's result arrives afterward.

The regression testing guide provides the larger replay discipline. Version fixtures and label changes, because moving the reference boundary can alter a metric without changing the actual agent.

Choose a policy with paired replay

Compare policies on the same frozen corpus before running a live experiment. Change one endpoint owner or hold rule at a time so that a difference can be attributed to a specific choice.

A silence-only baseline is useful because it is understandable. Add structure-aware holds, then semantic evidence if needed, and compare where each policy helps or fails rather than assuming that a more complex controller is automatically better.

The LiveKit tuning guide documents several endpointing modes and timing controls. Read their effective relationship for the current version, especially whether a delay is added after a provider endpoint or combined with a VAD silence period.

Do not compare configuration numbers as if they were observed latency. A setting describes an input to the policy; queueing, recognition, scheduling, and playback determine what the caller experiences.

Report early-cutoff counts by fixture family and waiting delay only on eligible completed cases. Preserve unresolved and missing-endpoint counts as separate outcomes, and include the number of cases behind every summary.

A release decision should combine task risk and interaction cost. A small increase in waiting may be acceptable when it prevents incomplete identifiers, while a policy that waits on every short answer may make ordinary confirmations frustrating.

Distinguish component and task outcomes

Endpoint correctness asks whether the application closed at an acceptable answer boundary. Task correctness asks whether the final accepted list, name, or action matches the caller's intended outcome.

Measure both. A late endpoint can still lose a letter through normalization, and a perfectly timed endpoint can feed an unauthorized tool call. The outcome metrics guide explains how to preserve those distinctions in reporting.

Use a task-level negative case where the current prefix is syntactically valid. That fixture exposes controllers that declare success because the parser accepts the buffer, even though the caller later adds a material suffix or item.

Include caller repairs after read-back. If the agent can recover cleanly, record the recovery cost and final task result; do not hide the original cutoff simply because the conversation eventually succeeded.

Keep a rollback condition

Before deployment, define which observed failure would revert the policy. Examples include a newly missed short correction, a repeated no-input loop during spelling, or a rise in unsupported closes on a monitored slice.

The condition should point to a known version and configuration. A vague instruction to "increase the timeout" is difficult to execute safely when several components own different waits.

Keep the operational packet small: fixture version, label policy, recognizer and endpoint configuration, application hold behavior, and remaining gaps. That is enough to make an on-call decision reviewable without copying raw caller content into an incident channel.

Conceptual: Judge an online endpoint against the evidence available when it acted, with unresolved cases retained.

Handle deployment failure cases

Structured collection depends on the entire media path. A browser may stop delivering timely callbacks, a recognizer may finalize unexpectedly, or a caller may change devices midway through a task.

Treat input-path failure separately from semantic incompletion. If the audio stream is disconnected, asking the caller to continue a spelling sequence may repeat a prompt they cannot hear or answer. Check transport state before deciding that silence reflects hesitation.

The SIP troubleshooting guide distinguishes signaling from working audio. A connected call can still have one-way media, and a no-input timer is a poor detector for that condition.

On web clients, use the mobile browser test matrix. Backgrounding and device changes belong in endpoint evaluation when they affect the delivery of speech, transcripts, or control events.

Support interruption during collection

The caller may interrupt a clarification with a correction or a new answer. Stop the obsolete prompt and preserve the new speech under the current input scope, provided the task has not changed.

A short acknowledgment during a clarification is different from a request to stop. The backchannel floor policy keeps that decision separate so that the endpoint controller does not become an accidental overlap classifier.

If an interruption changes the question, invalidate pending completion callbacks. The input buffer should never combine the end of the previous question with the start of the new answer merely because both arrived on one stream.

A clear separation among audio segmentation, floor ownership, answer collection, and business validation makes these races easier to reproduce. Each layer has a smaller invariant and a traceable owner.

Keep privacy in the corpus design

Spelled names and identifiers can be sensitive even when the audio sounds mundane. Use synthetic fixtures for code examples, and govern real recordings with the consent, access, and retention rules appropriate to the deployment.

Do not publish actual names, phone numbers, or complete identifier sequences to make a benchmark look realistic. Synthetic fixtures can exercise character ambiguity and repair without exposing a customer or caller.

For a managed system such as 60db Agent, evaluate the public observable behavior with the same contract. Ask what input and playback evidence is available, then measure the actual integration rather than assuming anything about an unpublished internal architecture.

Review a concrete rollout packet

Before changing the live policy, give the operator a concise packet containing the current question contract, the failing fixture, the proposed rule, and the rollback version. Include the effective endpoint owner and the evidence that will indicate improvement. An isolated timeout value is insufficient when a provider, framework, and application each contribute a wait.

Review the accepted field after every mandatory fixture, rather than checking only the endpoint timestamp. A correctly delayed reply that stores the wrong spelling is still a task failure, and a correct final list reached through repeated cutoff repairs still carries an interaction cost worth recording.

Keep cohort labels broad enough to protect callers while preserving diagnostic value. Device class, language, and input contract can explain a failure without retaining a raw surname in the operational report. Use governed replay identifiers for deeper review, and make deletion of the associated evidence effective across copied reports as well as the original recording store.

Finally, record the limits of the release. A spelling corpus from one language and one capture path does not validate list collection across all devices. Name the tested scope so that future expansion starts with a known contract rather than an assumed generalization.

---

Frequently asked questions

What is end-of-turn detection for structured speech?

It is the decision that a caller has finished the answer requested by the current question. For lists and spelling, that decision needs the expected structure as well as acoustic and semantic evidence. Keep it separate from recognition finality and field validation so that a finalized audio segment does not prematurely close an unfinished answer.

Why do lists get cut off after a pause?

A silence-based endpoint can treat an inter-item pause as the end of the whole answer. The controller may then validate or act on a partial list. Preserve provisional items and require a task-specific completion signal or clarification. A valid current item does not establish that there are no more items to come.

Does semantic VAD solve spelling pauses?

Semantic VAD supplies completion evidence, but spelling has a structure that differs from ordinary sentences. A complete letter group may still be a prefix of the intended name. Evaluate the actual spelling task, keep an explicit collection scope, and use read-back or clarification rather than assuming a semantic detector knows the intended sequence length.

Should an ASR final result close the answer?

An ASR final result closes a particular recognition result under the provider's contract. It does not necessarily close the user answer. Keep final results associated with their audio portions and aggregate them under the current question until the application's completion contract is satisfied or the controller moves to clarification.

How should an unfinished sentence be handled?

Keep listening when the available evidence indicates an unfinished dependency, such as a condition or explanation that the caller has begun. Bound that wait and ask a targeted clarification if the caller does not continue. Do not fill the missing clause from a plausible guess when it would change the requested task or action.

Is a longer silence timeout always safer?

A longer timeout can reduce some premature endpoints while making completed answers feel slow. It also does not solve list scope, recognition revisions, or field repair. Compare policies with paired replay, report early cutoff and eligible waiting delay separately, and choose a task-aware rule that addresses the observed failure rather than extending every wait.

How do explicit completion phrases help?

A scoped phrase such as "that's all" gives a variable-length collection a visible end condition. It still needs interpretation in context because the phrase could be quoted or misrecognized. Support callers who omit it by asking whether the list is complete instead of treating the missing phrase as an automatic failure.

What should happen when the waiting budget expires?

Move to clarification or another explicit fallback. Budget expiry means the application has waited as long as its policy allows; it does not prove that the intended answer is complete. Preserve collected items or characters and ask only about the missing boundary, unless a transport failure requires a different recovery path.

Can a parser determine whether a name is complete?

A parser can validate syntax and known constraints, but a valid prefix may still be incomplete. Names and many identifiers have variable length. Use the parser after the answer boundary closes, and confirm uncertain values through read-back. Do not use parser acceptance alone as permission to stop listening or commit an action.

How should "B as in Bravo" be stored?

Under a typical spelling contract, it contributes the intended letter B and supporting evidence about that interpretation. Keep normalization separate from raw recognized words. If the phrase is uncertain, preserve the uncertainty and clarify rather than appending every word literally or silently selecting a character that the caller did not confirm.

What if the caller changes an earlier letter?

Treat the statement as a field revision with an explicit target position or scope. Avoid concatenating the old and new sequences. If the correction target is unclear, ask which part should change. The endpoint controller should preserve the open answer while a revision ledger decides which provisional characters remain current.

How do you label a completion boundary?

Write an annotation rule that names the reference event, such as the end of a meaningful answer under the task contract. Include the preceding question and mark unresolved cases explicitly. Keep acoustic end time distinct from conversational completion so that reviewers do not mix two different boundaries in the same delay metric.

How should early endpoints enter latency reports?

Report them as cutoff errors rather than negative waiting times. A policy that responds before completion should not appear faster because it interrupted the caller. Calculate waiting delay on cases with an eligible reference completion and a candidate endpoint at or after that boundary, and publish the excluded error counts beside the delay summary.

What is an unsupported close?

An unsupported close occurs when the application declares completion even though the reference fixture has no completed answer. A caller who trails off may belong in this category if the policy invents a final value. Keep it separate from early cutoff, which assumes a later reference completion exists and can be compared.

Can text replay replace audio replay?

Text replay tests application logic and revision handling. Audio replay also exercises capture-independent recognition and acoustic endpoint evidence, while live device tests add the media path. Use each for a stated purpose and report its limits. Passing a text fixture cannot establish acoustic performance or caller-perceived timing on a phone or browser.

Why do endpoint settings from different SDKs differ?

Different components may apply a wait after different events or combine it with provider timing in different ways. Read the current effective contract and identify the owner of each boundary. Comparing raw configuration values without their semantics can hide added delay or create two components that independently close the same turn.

How do duplicate events affect collection?

Duplicate finalization or endpoint events should repeat the same state outcome without producing another read-back or action. Revised evidence for an existing segment must still update the buffer. Use result identity and version, and tie callbacks to the current answer scope so stale events cannot close a replacement question.

What should a no-result recognizer response mean?

It should retain the distinction between no recognized speech and the possible causes of that observation. Silence, poor capture, configuration mismatch, and service failure require different recovery. Consult media and recognizer status before issuing another prompt, and avoid turning every empty result into a semantic claim that the caller supplied nothing.

How should a multilingual corpus be organized?

Include language-specific list forms, spelling conventions, code-switching, and pause behavior with reviewers familiar with the intended task. Keep per-language counts and disagreements. A pooled metric can conceal failures in a smaller slice, and translating an English continuation list does not prove that the endpoint contract works for another language.

What should be tested before release?

Test open lists, completed lists, spelling pauses, corrections, unfinished clauses, explicit waits, missing input, duplicate events, and stale callbacks. Verify final accepted values as well as endpoint timing. Keep the policy version and fixture revision with the report, and make unresolved cases visible so the release decision reflects the evidence you have.

Validate the next boundary

Start with one structured question that already causes repeated caller repair. Write its completion contract, create paired fixtures around its ambiguous pause, and run both the state-machine assertions and the media-path replay before changing a timeout.

Use the voice regression testing workflow to retain the failure as a permanent fixture. Ship a policy whose boundary and fallback you can explain, then expand the corpus with observed, appropriately governed evidence rather than assuming one endpoint setting fits every answer.