Voice Interaction Design Guidelines

For designers and engineers: let the system hear accurately, let users interrupt at any time, let speech be short enough to remember, let what's forgotten be askable again, let the identity behind a voice be unambiguous, let those present know what the microphone is doing, and always keep a path open that can get things done without speaking.

Voice compresses interaction into a channel that is linear, cannot be skimmed, and cannot be looked back over. On a screen, a user can glance first and then decide whether to read; in voice, the user must finish listening before knowing whether it was worth listening to. On a screen, information stays put waiting for someone to come back to it; in voice, once said it is gone. At the same time, there is often more than one person in front of the microphone, and often more than one person beyond the speaker as well.

The object of voice-interaction design is therefore not "scripted phrasing." The objects of design are: the system's reception and understanding of the user's utterances, the holding and yielding of turn-taking control, the system's speech output itself, the listener's short-term memory, the identity carried by a synthesized voice, the physical space the microphone occupies, and the entry into and exit from this voice channel.

These guidelines consist of seven principles and 47 rules: principles state the design direction, rules specify applicable situations, behavior requirements, and verification methods. Each rule belongs to one and only one principle, and the rule number is the principle number (V3-2 is the second rule under the third principle).

These guidelines constrain the nature of the experience commitments a product makes to users in voice scenarios and the mechanisms that honor them; they do not presuppose a single technical architecture, are not bound to any one vendor's recognition, synthesis, or real-time calling solution, and do not distinguish between cascaded pipelines and end-to-end voice models — the experience commitment is the same under both architectures, only the mechanism of delivery differs. This is not a scripting manual, not a dialogue-flow template, and not a tuning guide for voice engines.

Adopting these guidelines cannot substitute for dedicated assessments of accessibility, privacy, security, and domain compliance. Voice scenarios significantly amplify three categories of risk, making these dedicated assessments more necessary rather than less so compared with graphical-interface products: when hearing is the only channel, cognitive and perceptual differences directly determine whether a task can be completed at all; what a microphone captures is a physical space, and third parties never consented to it; disclosure of a synthesized voice's identity is already a statutory obligation in multiple jurisdictions, not a design choice.

Four chapters in all: Chapter 1 principles, Chapter 2 how to read the rules and a quick reference, Chapter 3 rules in detail, Chapter 4 terminology; the verification checklist, basis notes, and a complete task example are in Appendices A, B, and C, with complete sources in reference.md.

---

1. The seven principles¶

The seven principles divide design responsibility by object of regulation: each principle governs obligations on one category of object, and each rule belongs to the single principle whose object matches the direct object of that rule's obligation. Different objects mean the principles never substitute for one another — this is both the basis for the division and the way to test it.

A single scenario can touch multiple principles at once — a user in the living room interrupting a speaker that is reading out a balance touches the immediate effect and consequence of interruption (V2-1, V2-2), the presentation level of speaker output (V6-4), and the delivery of what was interrupted (V4-1) at the same time — this is not a classification error: the three rules constrain obligations on three different objects of regulation, one being turn-taking control, one being physical space, and one being the listener's access to information. Mutual exclusivity and exhaustiveness are claims this division accepts being tested against, not facts established by declaration: when a rule's addition, removal, or assignment is in doubt, verify it against the classification test in Appendix A. If the test fails, what gets revised is the division of principles.

The three boundaries within this division that most need ongoing testing are stated here:

• V1 and V6 — whether a bystander's speech should be treated as a command is a question of command provenance (V1-6); whether a bystander's voice can be retained and used is a question of privacy and consent (V6-3). For the same piece of audio, the two rules constrain two different things.
• V3 and V4 — speaking briefly governs the output itself (length, structure, density); a remedy for forgetting governs the listener's after-the-fact ability to recover (repetition, stepping back, extended time). Doing the former well can reduce how often the latter is needed, but it cannot substitute for it.
• V2 and V7 — interruption is reclaiming the turn within the voice channel; a way out is leaving the voice channel. A user shouting "stop" and a user switching to typing are two different things.

If these three boundaries repeatedly produce disputes over assignment in practice, the division of principles should be adjusted rather than adding an intermediate layer.

Principles are for understanding rules and adjudicating assignment; they are not themselves a separate item for determination. When a principle's reading conflicts with that of a specific clause, the applicable clause governs, and the ambiguity that needs clarifying is recorded.

A rule's assignment being unique does not mean a mechanism cannot be reused. The same timing facility can support both endpoint determination (V2-3) and response waiting (V4-3), but the two must keep separate start events, resets, and expiration actions; a single "visibility-level resolution" can serve both speaker output (V6-4) and the adjudication of screen-forwarded content (V7-1). A single mechanism serving multiple purposes is the norm; which rule it is written under depends on the direct object of regulation of the obligation.

2. How to read the rules¶

2.1 The structure of each rule¶

In one sentence, the force of each part: the rule text states the requirement; Applies to and Boundary conditions together bound the scope of the requirement; Design application, Verification examples, Counterexamples, and Basis and references add no separate obligation.

A rule states the nature of the behavior, not the implementation: that the system stops speaking within a perceptible time after the user starts talking is product behavior; whether that is determined with VAD plus an energy threshold or an end-to-end model is an engineering approach — the two must agree with each other, but they are not the same deliverable.

These guidelines do not prescribe performance thresholds that are universal across products. For parameters such as first-audio latency, silence threshold, single-turn length limit, or the cap on parallel list items, a rule only requires that it be "clearly defined, justified, and verifiable." This is not evasion: these values vary enormously by language, task type, user population, and deployment environment, and the cited sources do not support a single performance threshold that holds across scenarios. Engineering parameters are recorded in reference.md §4, as an implementation-mapping reference rather than a compliance basis.

2.2 Normative terms¶

The rule text uses normative terms at three levels:

• MUST: not meeting it means not conforming to these guidelines. Without it, some commitment made to the user would fail under a foreseeable situation — this is the sole basis for marking something "MUST."
• MUST NOT: the negative counterpart at the same strength as "MUST," identifying behavior that must not occur; "MUST NOT" and "forbidden" are equivalent in the text.
• SHOULD: followed by default; when there is genuine reason to deviate, record the rationale and alternative, and accept the same verification. Deviation needs no approval, but it does need to be documented. "SHOULD NOT" is the negative counterpart of "SHOULD."

Compliance is judged at the level of the independent obligation clauses in the text: a declarative sentence without a normative term carries the strength of the heading of the rule it belongs to; a clause with an explicit normative term is judged at its own strength — a "MUST NOT" clause inside a [SHOULD] rule remains a hard constraint (V2-4, V3-2, V4-4, V5-5, and V7-4 contain such clauses), and strength annotations on rule headings or the quick-reference table do not replace clause-level binding force. "Cannot" in the text is used only for statements of capability or fact, never to express an obligation.

Strength expresses binding force, not importance.

2.3 The two sides of a counterexample¶

Counterexamples have two sides: "under-delivery" is missing this requirement; "over-delivery" is piling on confirmations, repetitions, tones, and fallback scripts in order to satisfy it. Neither side counts as getting it right — the way voice products go wrong is heavily concentrated on the latter: repeating every sentence back for the user to confirm, reciting a capability statement and disclaimer before every answer, holding back a response to avoid a false interruption until the user thinks the call has dropped, or stuffing every sentence with "um," "okay then," "I understand how you feel" for the sake of sounding "natural." Redundancy in voice costs far more than redundancy on a screen, because it consumes time rather than space.

2.4 Rule quick reference: 47 rules¶

The table below is the one-sentence memorable version of every rule; click a rule name to jump to its full text in Chapter 3. The quick reference does not replace each rule's applicability conditions and full requirements; a few [SHOULD] rules contain forbidding-level clauses (V2-4, V3-2, V4-4, V5-5, V7-4), and the main text governs the determination (see 2.2).

V1 Hearing accurately

V2 Turns have an owner

V3 Speaking briefly

V4 A remedy for forgetting

V5 The voice has an owner

V6 Presence is knowable

V7 There is a way out

2.5 Design deliverables and operational facts¶

Reviewing each applicable rule answers three questions: what behavior the product chooses, what facts engineering uses to prove it happened, and how the user knows and can correct it. The table below is a design and verification method; it adds no new rule and requires no separate deliverable.

These dimensions can run in parallel: the system can still receive an interruption while it is playing back, and the microphone may also be off while a task is processing. A single mutually exclusive "listening / thinking / speaking" animation cannot stand in for all states; when a waveform is used to express that audio is currently being captured, the waveform must come from the actual input — a looping animation must not fake capture. Audio energy only proves input activity; it proves neither source, meaning, nor authorization.

Control and data events must be associated with the same task, session, turn, or output segment, and must record when they occurred and the source of the fact. A late-arriving event must not overwrite a new state with an old one: a recognition result that arrives after exit must not initiate an action, stale audio must not be re-queued after a stop, and an expired confirmation must not be matched to a new question. Whether to use event sequence numbers, cancellation flags, or some other mechanism is an engineering decision; what is verified is the behavioral outcome of these events.

2.6 From task to solution¶

First select two or three real tasks, write out their completion conditions, key values, and irreversible consequences, and then compare the benefits of push-to-talk, tap-to-submit, and automatic endpointing. Choose the approach using target users' actual pauses, environmental noise, and the cost of accessible controls; do not default to continuous capture just because it feels "more human."

For each task, map out the paths for starting, correcting, confirming, executing, recovering, and exiting. At each key node, record the default behavior, user control, failure exit, and the facts needed; use Design Token once there is a parameter trade-off to make. The normal path and the abnormal path share the same task state. Appendix C gives one complete example.

3. Rules in detail¶

This chapter lays out all 47 rules by the seven principles. Each rule's structure and the binding force of its parts are given in 2.1; the design applications, verification examples, and counterexamples within it are only explanations that aid implementation — they do not prescribe a single component, and they do not require a new separate deliverable document.

3.1 V1 Hearing accurately¶

The most common first-layer error in voice products is treating the output of speech recognition as what the user said. It is not — it is a hypothesis that may be wrong, and its quality must be verified separately by accent, noise, proper nouns, and atypical speech. This principle governs how this hypothesis is established, how it is checked, what to do when it is wrong, and the boundary between "the sound that was heard" and "the user's command."

V1-1Recognition results are a hypothesis, not a factMUST¶

In one sentence: Recognition can be wrong; without reliable confidence, an irreversible action must not be executed on a guess either.

Applies toany product that takes voice as input.

Rulethe product MUST treat speech-recognition results as a hypothesis carrying uncertainty, not as certain user input. The system MUST be able to distinguish "high-confidence understanding" from "low-confidence understanding," and use that distinction as an input to downstream processing. Low-confidence understanding MUST NOT directly trigger an irreversible action (sending externally, payment, deletion, public posting, permission changes, and the like, as defined by the product's actual consequences — recognition accuracy MUST NOT be substituted for a judgment of consequence); in such cases the flow MUST move to confirmation, clarification, or completion through another modality. When recognition confidence is unavailable, treat it as low confidence.

The signal used to distinguish confidence tiers MUST be calibrated with measurements under the target language, user population, and environment; the model's own claim of "I heard you clearly," utterance fluency, or overall success rate MUST NOT be treated as evidence that a single input was correctly understood. Intermediate results from streaming transcription MUST be treated as revisable content; when a revision affects a key object or consequence, any prior confirmation based on the old content MUST become invalid and be re-checked.

Boundary conditionsthis rule does not require displaying a confidence value to the user, nor does it require interrupting the user on every instance of low confidence — V1-2 specifies how confirmation strength varies with consequence, and V1-3 specifies how to change strategy after repeated failures. This rule requires that the basis for uncertainty be clearly recorded internally; when no reliable basis exists, keep it as "unknown" rather than fabricating a confidence score.

Design applicationdesign "confidence" as an input that runs through the whole pipeline, rather than debug information internal to the recognition module. When an end-to-end voice model does not separately output a transcription confidence, keep "confidence unknown" and route it into checking based on consequence. Repeat-back rate, clarification rate, and interruption rate are used to evaluate system quality; they must not be treated directly as the probability that the current utterance was correctly recognized.

Verification examples

• User side: say a command that would trigger an irreversible action in an environment with background noise, and observe whether the system executes it directly or moves to confirmation.
• Implementation side: verify that the low-confidence path genuinely exists and is triggered, not merely a threshold that exists in name only; verify that when confidence is unavailable, the system takes the conservative branch.

CounterexamplesUnder-delivery — hearing "transfer to Zhang Wei" in a noisy environment and transferring the money directly; over-delivery — requiring the user to repeat and confirm every single sentence, including a one-second-reversible action like "turn off the light."

V1-2Confirmation strength matches the consequenceMUST¶

In one sentence: How much confirmation is needed depends on whether the consequence is reversible, not a repeat-back on every sentence.

Applies toproducts where voice input triggers a state change or an external action.

Rulethe product MUST define a confirmation strategy for voice input, and the confirmation strength MUST be determined by the reversibility of the consequence and the scope of its impact, not by recognition confidence alone. The strategy MUST distinguish at least three tiers: no confirmation (the consequence can be undone immediately and its impact is limited to the current session), implicit confirmation (the next response carries the understood key elements and continues within the existing scope of authorization), and explicit confirmation (the system pauses and waits for the user's explicit response). An irreversible action MUST use at least explicit confirmation, and what is confirmed is the action and its consequence itself, not "was this what you just said." The content a confirmation is based on MUST match what will actually be executed.

Implicit confirmation is not a form of authorization, and silence does not create new permission. An explicit response MUST be tied to the specific action and content snapshot already disclosed in this turn; an "mm-hm" heard before the announcement has covered the necessary object and consequence MUST NOT be treated directly as consent to that action. When a user self-corrects within the same sentence ("not Thursday, Friday"), the system MUST process the complete correction before checking, and MUST NOT submit on catching only the first half. A confirmation MUST be bound to a specific object, key value, consequence, and valid condition; if any one of these changes, the old confirmation becomes invalid. A vague response, background sound, or an expired confirmation MUST NOT authorize a new action.

Boundary conditionsthis rule does not require a separate scripted template for each confirmation tier; nor does it prohibit turning off implicit confirmation on low-consequence actions once the user has explicitly expressed that preference.

Design applicationimplicit confirmation is the most time-efficient tier in voice, and should be the default for intermediate steps — "okay, shipping to the office address, arriving Wednesday" is both a confirmation and a progress update at once. Reserve explicit confirmation for money, anything sent externally, deletion, and permissions.

Verification examples

• User side: have the user repeat back what they are approving at the explicit-confirmation point, and check whether their statement matches what the system is about to execute.
• Implementation side: enumerate every action with an external effect and check whether its confirmation tier maps to its consequence tier without gaps.

CounterexamplesUnder-delivery — "delete all recordings" is executed directly once recognized; over-delivery — even a weather query gets "did you mean you want to check today's weather?"

V1-3When it doesn't understand, change strategy, not repeat the questionMUST¶

In one sentence: After repeated failures to understand, change how the question is asked, switch modality, or transfer to a human — don't play the same prompt a third time.

Applies tovoice flows where recognition failure, unmatched intent, or repeated clarification can occur.

Rulethe product MUST define an escalation sequence for when recognition fails or understanding is not possible, and MUST specify a total maximum number of attempts per level and per current question; once that cap is reached, the flow MUST move to the next level — repeating the same prompt in the same wording beyond the declared number of times is prohibited, and looping through clarification indefinitely with no new information is also prohibited. The escalation sequence MUST include at least one instance of rephrasing or narrowing the question, and MUST end at switching modality or transferring to a human (the availability of that endpoint is covered by V7-2 and V7-5). Each escalation MUST retain information the user has already provided; progress MUST NOT be cleared because of an escalation. The system MUST distinguish between no input received, input heard but not recognized, text recognized but not understood, and a permission or connection fault; it MUST NOT ask the user to "say that again" when the microphone is unavailable. Waiting for the user to start speaking is handled under V4-3 and does not consume the recognition-failure count. The count is scoped to the current unresolved question, and only resets on successful resolution, an explicit task switch by the user, or exit; changing the wording, model, or input channel by itself does not reset the total failure budget — reaching the total cap moves directly to the available endpoint. When the user actively requests a modality switch or a transfer to a human, handle it immediately without needing to complete the escalation sequence.

Boundary conditionsthis rule does not require every product to provide a human agent — for a product that does not transact business on behalf of an institution (such as device control), "switching modality" or "clearly stating the task cannot be completed and offering a viable alternative" may serve as the endpoint, but that endpoint MUST be explicitly declared and MUST NOT be replaced by silent failure.

Design applicationfor example, change the phrasing on the second failure, then switch modality or transfer to a human afterward; the exact counts are determined through scenario-specific verification. Compare the completion rate and user burden of narrowing scope versus repeating the prompt before settling on an escalation strategy.

Verification examples

• User side: give a sequence of inputs the system cannot recognize, and record how many turns it takes to reach a usable way out, and whether information provided earlier is still retained.
• Implementation side: check the reset conditions of the escalation counter; verify that reaching the cap genuinely moves to the next level rather than looping back to the first.

CounterexamplesUnder-delivery — "sorry, I didn't catch that, please say it again" loops seven times until the user hangs up; over-delivery — transferring to a human immediately on the first failure to understand, pushing everything that could be self-served onto an agent.

Basis and referencesthe W3C COGA voice module explicitly states that "simple error recovery should move toward a human, rather than creating a frustrating loop" (see reference.md §2).

V1-4Atypical speech is not excludedMUST¶

In one sentence: Accents, dysarthria, and child or elderly speech going unrecognized is the system's problem, not the user's.

Applies tovoice products aimed at the general public; internal enterprise products may be analyzed by their actual user composition once that population is known.

Rulethe product MUST provide a completion path that does not depend on recognition quality (at least one of key-based input, text input, or an accessible human channel) for user populations whose recognition quality is systematically lower, and the reachability of that path MUST NOT be lower than the voice path. Reducing the range of functionality available to such a user because recognition confidence stays persistently low is prohibited, and describing a recognition failure as the user's expression problem is also prohibited. The product MUST declare the languages and accents its recognition capability covers — a single-language product also needs to declare this; "supporting only one language" is itself a coverage scope that must be stated; users outside that scope MUST be given the alternative path before entering the voice flow, or at the first failure, rather than after multiple rounds of failure.

Boundary conditionsthis rule does not require a product to claim it has achieved equal recognition rates across all languages and accents; what it requires is that differences in recognition rate do not translate into differences in available functionality.

Design applicationbuild the alternative path as an entry point rather than a fallback: "switch to keys" should be selectable right at the start of the flow, not appear only after three failures. Capabilities related to voice biometrics (V6-6) especially must not become the sole gate.

Verification examples

• User side: recruit participants with a noticeable accent, dysarthria, or non-native speech to complete the same task, and compare the completion rate and the cost of reaching the alternative path.
• Implementation side: verify that the alternative path does not require first going through failure to be entered; verify that the scope of functionality does not vary with confidence.

CounterexamplesUnder-delivery — the system repeatedly demands "please speak standard Mandarin" when it can't understand, with no other way out; over-delivery — as soon as an accent is detected, voice is skipped entirely and forced over to keys, depriving the user of voice interaction they could otherwise have completed.

Basis and referencesW3C NAUR requires providing non-voice alternatives for atypical speech and for deaf and speech-impaired users (see reference.md §2). The coverage and effectiveness still must be judged from evidence of target users completing tasks.

V1-5Critical content is preserved verbatimMUST¶

In one sentence: Names, numbers, and amounts must not be smoothed into more common wording.

Applies toproducts where voice input contains proper nouns, identifiers, numeric values, or content that needs to be recorded precisely.

Rulethe product MUST define a verbatim-fidelity domain — names of people, places, and organizations, order numbers and other identifiers, amounts, dates and times, addresses, and the like — whose actual meaning MUST NOT be silently rewritten, corrected, or "smoothed" by a language model or post-processing anywhere across the full pipeline from recognition to execution. The original utterance, the normalized value, and the confirmed value MUST be distinguishable; format normalization may use only declared, meaning-preserving rules, and ambiguous cases must be checked first. Content that falls within the fidelity domain and has insufficient confidence MUST move into a checking or spell-out flow; silently substituting a more common homophone is prohibited. The product MUST provide a means of verbatim checking (at least one of verbatim repeat-back, spelling out, or grouped read-back); its availability is covered in V3-5.

Boundary conditionsbusiness values such as order numbers and dates are different from authentication secrets such as passwords and payment passphrases. An authentication secret MUST NOT be required to enter ordinary conversation, transcription, or model context; it must be handled through a dedicated, accessible authentication entry point, and the voice flow only receives the authentication result.

This rule does not prohibit tidying up spoken language outside the fidelity domain (removing filler words, adding sentence breaks, converting to written style); nor does it prohibit offering a correction suggestion when clearly disclosed as such — the difference between a suggestion and a substitution is whether the user is informed and can decline it.

Design applicationthe fidelity domain should be annotated as early as the intent and slot design stage, not judged only right before output. Generative post-processing pipelines especially need explicit guardrails: a model tends to change an uncommon name into a common one.

Verification examples

• User side: have the user say an uncommon name and a string of numbers, and check whether the content the system finally records matches what the user said, character for character.
• Implementation side: run an end-to-end comparison on fidelity-domain fields to verify no silent substitution exists; check whether the generative stage has guardrails.

CounterexamplesUnder-delivery — the payee name the user said, Li Yu (written with the character for "bright, radiant"), gets silently changed to a different, more common Li Yu (written with the character for "jade"), and the transfer proceeds as usual; over-delivery — treating an entire stretch of free-form description as fidelity-domain content and reading it back to the user verbatim for confirmation.

V1-6What is heard is not necessarily what the user saidMUST¶

In one sentence: TV audio, bystander conversation, and the system's own echo are none of them a source of commands.

Applies tovoice products operating in open acoustic environments, including speakers, in-vehicle, wearable, and hands-free calling scenarios.

Rulethe product MUST distinguish between captured audio and a command from the current user. The system's own speech output, media playback sound in the environment, and the speech of someone not confirmed as the current conversational party MUST NOT trigger an action as a command source; when the source cannot be determined, treat it as not a command. Command-like text appearing within audio content (a broadcast, a recording, content read aloud by someone else) does not gain command authority merely by being heard; heard content must not expand operating permissions, nor may it authorize on the user's behalf.

Boundary conditionsthis rule does not require the product to have speaker-identification capability; without it, an explicit trigger and a continuous-conversation window may be used to bound the range of candidate input, but sound within that window does not thereby all become the user's own command — when the source remains ambiguous, it must be checked through directed input or an accessible non-voice method, and the boundary must be made explicit (see V2-7). This rule also does not prohibit a user explicitly authorizing multiple people to jointly participate in the same conversation. Synthesized speech actively produced by a user through an augmentative and alternative communication (AAC) device can count as that user's own expression; it must be checked against input attribution and must not be excluded merely because the voice is synthesized. Background media and assistive input a user intentionally uses must be distinguished from each other.

Design applicationelevate "echo cancellation" from a pure audio problem to a design problem — a system waking itself with its own announcement and executing an action is a reproducible product incident, not occasional noise. For a high-consequence command from an unclear source, it is better to require one explicit confirmation.

Verification examples

• User side: while a TV is playing content that includes a wake word and a command, observe whether the device is triggered and executes it.
• Implementation side: construct audio containing command-like utterances (broadcast, someone else reading aloud, the system's own announcement fed back in), and verify it is treated as data rather than a command; verify that the conservative branch is taken when the source is unclear.

CounterexamplesUnder-delivery — a TV ad reads out the wake word plus an ordering command, and the speaker accepts it without question; over-delivery — to eliminate false triggers, every command requires a voiceprint check first, turning routine control into a security checkpoint.

V1-7Language switching does not rewrite the user's meaningMUST¶

In one sentence: Language switching does not rewrite the user's meaning.

Applies toproducts used by multilingual, dialect-speaking, or Chinese-and-foreign-language code-switching users.

Rulethe product MUST separately declare the languages and regions covered by recognition, endpoint determination, and synthesized output, and MUST NOT assume that recognition supporting a given language means the entire voice pipeline supports it. A language the user has explicitly selected MUST remain modifiable; when automatic detection conflicts with it, the user's selection MUST be preserved and a correction entry provided. Switching languages mid-task MUST NOT clear collected information or change key values; when reliable handling is not possible, provide a way out per V1-3.

Boundary conditionsthis rule does not require supporting every language, nor does it require automatic language detection; whether intra-sentence code-switching is supported MUST be stated explicitly and verified through testing.

Design applicationChinese-language tasks can cover input such as saying "move the meeting to Friday" with an English word embedded in a Chinese sentence, names with multiple possible readings, and identifiers that mix Chinese characters with letters; a name like Li Yu, where the speaker disambiguates it as "the Yu written with the sun radical," still needs its final character checked rather than resolved from the homophone reading alone. Numeral localization is handled per V3-5.

Verification examples

• User side: within the same task, switch between Chinese, English, and any declared code-switching, and check whether information, dates, and objects stay consistent.
• Implementation side: check ASR, endpointing, and TTS capability and fallback paths separately by language, rather than substituting a single overall accuracy figure.

CounterexamplesUnder-delivery — just because the user said one English product name, the entire flow switches to English and re-asks for the address; over-delivery — asking the user which language they want to use on every single turn.

Basis and referencesthe need for language coverage is discussed in reference.md §2; the specific Chinese-language examples are this guideline's own design derivation and must be verified through target-task testing.

3.2 V2 Turns have an owner¶

Voice usually unfolds around one primary turn, though backchanneling, overlapping speech, or full-duplex interaction can also occur. Who is speaking, when it is okay to interject, when a turn counts as finished, and how long to wait afterward — things that face-to-face communication negotiates through countless subtle signals — must be explicitly designed in a product. Two directions of getting this wrong are equally common: the system hogs the floor until it finishes, or the user is interrupted mid-thought before they've answered. This principle governs turn-taking control itself.

V2-1Interruption is available at any time and takes effect immediatelyMUST¶

In one sentence: Stop speaking promptly when the user initiates an interruption; don't force the user to wait for the sentence to finish.

Applies toany product that actively plays voice output.

Rulein an interaction with voice input enabled, the user MUST be able to interrupt the system's voice output by speaking at any moment, and the product MUST declare an upper bound on the time from detecting that the user has started speaking to the system actually stopping its output, and MUST make that bound achievable under real-world conditions. Except for segments that are legally or safety required and must play in full, voice output the user cannot interrupt is prohibited; where such a segment exists, its scope, reason, and duration MUST be declared in advance, and interruptibility MUST resume immediately once the segment ends. Beyond voice, the product MUST also provide at least one stop method that does not depend on speaking (a key, touchscreen, or gesture) for users who cannot speak up in time or are in an environment where speaking is inconvenient.

When voice input has been turned off by the user, microphone permission has been revoked, or a key-activated input mode is in use, an immediately available non-voice stop entry MUST be retained, along with an explanation of how to re-enter voice input; reopening the microphone on its own initiative just to satisfy voice interruption is prohibited. Verification of stopping speech MUST cover audio already buffered on the playback side, not merely verify that generation stopped on the server side; it must also record the elapsed time from the user's actual start of speaking to detection of that start, to avoid detection latency masking actually slow stopping.

Boundary conditionsrequiring that a disclosure be completed is not the same as requiring that it be heard in full by force. An exception to voice interruptibility MUST have a clear domain basis and MUST cover only the necessary segment; the non-voice entry to stop playback, exit, and revoke capture permission remain available, an incomplete disclosure is supplemented per the actual state, and the exception MUST NOT be used to block exit.

This rule does not require making every non-voice sound (a tone, the other party's voice during a call) interruptible; it constrains the product's own voice output. It also does not specify the sensitivity of interruption detection — that is the scope of V2-4.

Design applicationbuild interruption as a basic control: the playback side clears its buffer, the task side handles cancellation separately, and each gives its own receipt. Stopping model generation alone is not enough to honor the stop-speaking commitment.

Verification examples

• User side: interrupt while the system is reading out a long passage, and measure the actual time to stop speaking and the user's subjective experience.
• Implementation side: repeat the stop-latency measurement under weak network, high load, and long-text synthesis conditions, and verify it still stays within the promised bound.

CounterexamplesUnder-delivery — the user shouts "stop" three times and the system finishes reading a two-minute set of terms anyway; over-delivery — the interruption threshold is tuned so low that a single cough interrupts playback, forcing repeated restarts.

V2-2The consequences of interruption are unambiguousMUST¶

In one sentence: What wasn't played out doesn't count as disclosed; what has already been done doesn't disappear just because the system went quiet.

Applies toproducts where voice output carries a disclosure obligation, or where voice playback runs in parallel with an actual action.

Rulecontent that was interrupted and not played out MUST NOT be counted as delivered to the user; the product MUST be able to distinguish "played" from "generated but not played," and decide accordingly whether that content needs supplementary delivery (see the supplementary-delivery paths in V4-1 and V7-4). An interruption only terminates voice output; it does not automatically undo an action already executed — an action that has already produced an external effect MUST be truthfully stated in the first response after the interruption, and the actual result and the revocable scope MUST be checked before any reversal; when it cannot be reversed, state the consequence that has already occurred and any feasible remedy. The product MUST distinguish between the two intents "stop talking" and "stop the task." When a user says an ambiguous control word like "stop" while an action is proceeding, the system MUST first stop speaking and pause any affected action not yet submitted, and then clarify the scope of the stop; asking for clarification while continuing to submit at the same time is prohibited. If it becomes clear that only reading aloud should stop, proceed with the task under the existing valid authorization; if cancellation is made clear, enter the task-stop path.

Subsequent conversational context MUST stay synchronized with actual playback progress; content that has been generated, sent, or entered the playback queue MUST NOT be treated as shared information the user has already heard. The unplayed portion may be cached for repetition and supplementary delivery, but it MUST be distinguished from "already played." A playback receipt at most proves that the device played a given piece of content; it does not prove the user understood or agreed to it. When playback position is unavailable, delivery MUST be kept as unknown, and full delivery MUST NOT be presumed. Control, playback, and recognition events MUST be tied to a specific turn or output segment; transcription, generation results, or an old playback queue arriving late after a stop or exit MUST NOT restart output that has already stopped or advance the task.

Boundary conditionsthis rule does not require generating a "here's what wasn't finished" summary for every interruption; the supplementary-delivery obligation covers only necessary disclosures and content the user actively requests.

Design applicationdesign "stop" and "don't do it" as two distinct things and distinguish them clearly in the receipt — "okay, I'll stop reading, but the transfer has already been sent" is an acceptable response; "okay" is not.

Verification examples

• User side: interrupt while the system is announcing "submitting this for you now," and check whether the user can tell from the subsequent response whether the submission has already happened.
• Implementation side: verify that unplayed content is not recorded as disclosed; verify that the interruption event and the action's execution state are recorded independently of each other.

CounterexamplesUnder-delivery — after the interruption the system goes quiet, the user assumes it was canceled, but the order was actually submitted; over-delivery — every interruption triggers a full recitation of a "content not yet played" list.

V2-3Determining that speech has ended has a basis and an upper boundMUST¶

In one sentence: State what basis is used to determine the user has finished speaking, and make sure the waiting has an end.

Applies toproducts that need to judge that a user's turn has ended in order to decide when to respond.

Rulethe product MUST declare how it determines that a turn has ended (silence duration, semantic completeness, a dedicated endpoint model, or a combination of these) and the resolvable source of the parameters involved, and MUST set a maximum wait for endpoint determination. That time limit starts counting from when a pause in voice activity is detected, and resets once the user resumes speaking; upon reaching the limit, the system MUST offer a prompt or status feedback that allows continued input — suspending the determination indefinitely is prohibited, and talking over the user because this timer has expired while the user is still in the middle of expressing something is also prohibited. Reaching the wait limit by itself does not constitute evidence that "the user has finished speaking," and directly executing an irreversible action on that basis is prohibited; such cases MUST move to confirmation or a question instead. When a turn is judged finished but the user had not actually finished, the user MUST be able to continue rather than having to restate everything from the beginning, and what was already said MUST NOT be discarded.

The time limit for waiting for the user to begin answering is handled per V4-3, and session-idle wind-down is handled per V7-6; neither may share a vague "timeout" definition with the endpoint time limit. An explicit submission mode such as press-to-start/press-to-end or push-to-talk need not use automatic endpoint determination, but it MUST declare the distinction between start, submission, and cancellation, and must provide an accessible method that does not depend on sustained pressing.

Boundary conditionsthis rule does not prescribe specific thresholds (see the numeric note in 2.1), nor does it presume any fixed relationship between the thresholds used in different scenarios — whether dictation should tolerate a longer pause than Q&A, for example, is decided by measured pause distributions for the target task and target users. This rule does not require the same determination method across all scenarios, but each one used MUST be declared. When an endpoint mechanism that outputs a score is used, the meaning of that score MUST also be declared (whether a high score means "finished" or "not yet finished"), along with the comparison direction and the model and score definition it belongs to; for a mechanism that does not expose a score, record it as not applicable and declare it by its native parameters — fabricating a probability value to fill the gap is prohibited.

Design applicationsimply shortening the silence threshold may increase talking-over; lengthening it may increase waiting. A semantic endpoint or explicit submission is a comparable alternative. Scenarios such as addresses, descriptions, and dictation should have their pause tolerance tested separately, and the user should be made aware that they can continue speaking.

Verification examples

• User side: have the user say a long command containing a mid-sentence thinking pause, and observe whether it gets cut off; after any cut-off, observe whether continuing to speak can pick back up.
• Implementation side: verify that the wait limit genuinely takes effect and triggers the conservative branch; verify that the first half of the utterance is retained when the user continues speaking.
• Implementation side: for an endpoint mechanism that outputs a score, verify that the comparison direction matches the meaning of the score — configuring a model where "high score = finished" as if it meant "high score = not finished" should be caught; when an engine or model upgrade changes the meaning of the score, the old threshold and old verification evidence become invalid together.

CounterexamplesUnder-delivery — the user pauses for two seconds halfway through reading out an address, and the system jumps in with "okay, your order has been placed"; over-delivery — to avoid ever interrupting, the wait is stretched to six seconds, making every turn feel like a dropped call.

Basis and referencescurrent industry parameters and endpoint-model implementation forms are given in reference.md §4, as an implementation-mapping reference rather than a compliance basis.

V2-4Both talking over the user and dead air count as failureSHOULD¶

In one sentence: Getting interrupted for taking a breath, and getting five seconds of silence after finishing, are two sides of the same problem.

Applies tovoice products whose primary form is continuous conversation.

Rulethe product SHOULD measure and tune "the system talking over the user before they finish" and "a long unresponsive period after the user finishes" as two ends of the same set of quality metrics, and SHOULD set an acceptable range for each. The product SHOULD distinguish backchanneling, thinking pauses, correction, and interruption based on context; expressions such as "mm" or "okay" MUST NOT be uniformly ignored in every situation based solely on a word list — the same expression may be an answer to the current question. If a backchannel word list is used, it SHOULD be configured by language and context, and MUST NOT suppress a clear stop, negation, or correction. Measurement SHOULD be based on real usage data, not lab recordings alone.

The product SHOULD declare how it recovers from a false interruption. Before automatically resuming playback, the system MUST confirm there is no pending stop, correction, or new input; an empty transcript does not mean there was no valid expression — a missed recognition caused by a speech impairment, a short word, or a dropped packet MUST NOT be attributed to noise by default. Recovery SHOULD continue from the actual stop position or the most recent complete semantic boundary, without restarting the whole task or re-executing anything.

Boundary conditionsthis rule does not require reaching any specific talking-over rate or response-latency value; what it requires is that both directions be measured together, rather than optimizing only one of them.

Design applicationlowering the wait threshold may reduce latency but increase talking-over; raising it may have the opposite effect. Observe the two together, and also check recovery after a false interruption — effectiveness cannot be judged from either metric alone.

Verification examples

• User side: record a batch of complete conversations in a real environment, annotate talking-over and dead-air events, and tally the rate of each separately.
• Implementation side: verify that the backchannel word set genuinely takes effect; verify that when parameters are adjusted, changes in both metrics are observed together.

CounterexamplesUnder-delivery — after launch, only average response latency is tracked, and talking-over incidents are discovered only through user complaints; over-delivery — to drive down the talking-over rate, the wait is uniformly lengthened across all scenarios, sacrificing the fluency of short commands.

V2-5Whose turn it is now is knowableMUST¶

In one sentence: Let the user know at all times whether the system is listening, thinking, or speaking.

Applies toany voice-interaction product.

Rulethe product MUST let the user determine at any time which of the states — listening, processing, speaking, finished — and their legal combinations the system is currently in, with at least one indication method that does not depend on vision (a tone, speech, haptics other than a light effect, or the rhythm of the speech itself). The state indication MUST reflect the true system state; presenting "listening" when nothing is actually being captured is prohibited, and presenting "processing" when there is no actual processing under way is also prohibited. In scenarios that cannot rely on vision — voice-only use, driving, or use by someone with a visual impairment — the non-visual indication is the sole means, not a supplement.

In full duplex, "speaking" can coexist with ongoing capture, and a background task can also keep processing while listening to user input; the state presentation MUST distinguish input reception, task processing, and output playback, and must not force a mutually exclusive four-state model that papers over the parallel facts. When the microphone is muted, permission is unavailable, or a connection fault prevents capturing audio, that limitation MUST be presented rather than continuing to show "listening." Starting capture MUST wait for a successful device acknowledgment; a declined permission, hardware being occupied, the device being unplugged, or an interruption from an incoming system call MUST NOT be displayed as the user going silent. Restoring a connection does not automatically regain capture permission that was revoked; an incomplete input MUST retain the portion reliably received and state the gap, rather than being treated by default as a complete command.

Boundary conditionsthis rule does not require a distinct tone for each of the four states; expressing them in a distinguishable way is sufficient. It also does not require continuous sound — silence itself can be a state expression when there is a clear prior agreement on it.

Design applicationa start-of-capture and end-of-capture tone can bound the interaction interval, but its discriminability still needs to be verified; scenarios that cannot rely on vision must provide some other usable feedback.

Verification examples

• User side: complete a conversation blindfolded or in a driving simulation, have the user report "whose turn is it now" at several points, and tally accuracy.
• Implementation side: verify the state indication is driven by real operational facts rather than played on an estimated duration.

CounterexamplesUnder-delivery — the speaker goes silent for three seconds, and the user cannot tell whether it is thinking or didn't hear, so they repeat themselves, causing a double input; over-delivery — every state transition plays a spoken line explaining "I'm thinking about that."

V2-6Long processing is not silentMUST¶

In one sentence: When the substantive answer is not expected to start in time, explain the real wait within the first-feedback budget and allow cancellation.

Applies tovoice products where retrieval, tool calls, or multi-step execution can exceed the normal response latency.

Rulethe product MUST declare a committed value for first-audio latency; when a substantive response cannot start in time, it MUST provide a genuine processing signal (a non-verbal tone, a brief filler phrase, or a progress announcement) within that bound. If there is still no feedback beyond the bound, this MUST be recorded as an overrun, with a degradation or exit option provided — playing a belated tone afterward does not cancel this overrun record. A statement made during processing MUST NOT be phrased as though the action has already completed or been executed, and a progress description inconsistent with the actual running state is also prohibited. When processing exceeds the declared duration, the user MUST be able to cancel, the cancellation MUST produce a receipt, and any impact already caused MUST be stated.

Latency MUST distinguish between first feedback and the start of the substantive answer, with the start/end events, measurement points, and overrun handling declared separately for each. A tone or filler phrase MUST NOT be counted as the substantive answer. Test events MUST distinguish at least the user's actual end of utterance, the endpoint being established, the first feedback starting to play, and the substantive answer starting to play; the wait for endpoint determination is part of the wait the user perceives and MUST NOT be subtracted from the statistics. When a given event cannot be obtained, mark it as a missing measurement rather than filling in zero or substituting the moment generation completed. Verification MUST cover endpoint waiting, processing, transmission, and playback buffering, and MUST record typical and tail latencies, the overrun rate, and the test conditions; the server-side time to first byte or an average value alone MUST NOT stand in for the user's actual wait. The cancellation entry MUST remain available throughout processing, not appear only after the overrun.

Boundary conditionsthis rule does not require announcing progress for every wait; it requires that a wait expected not to start the substantive answer in time be explained within the first-feedback budget. If the answer has already started, no further redundant prompt need be played. Reaching the budget with still no feedback MUST be recorded as an overrun, and a belated tone afterward does not make this measurement pass. This rule also does not prohibit using filler phrases — what is prohibited is a filler phrase whose content is untrue.

Design applicationthe content of a filler phrase should either be task-relevant and true ("checking prices at three vendors now") or stay neutral; filling a wait with "okay, I'll have this done for you right away" turns the wait into a false receipt.

Verification examples

• User side: artificially lengthen the backend response and observe how long it takes before the user starts repeating the command or believes the call has dropped.
• Implementation side: verify the in-processing signal is triggered by real operational facts; verify the cancellation path is available and its receipt is truthful.

CounterexamplesUnder-delivery — the user asks a complex question, the speaker stays silent for eight seconds, the user assumes it wasn't heard and repeats it, triggering two executions; over-delivery — every query first plays a line like "let me think about that, this is an interesting question."

V2-7Turn ownership when multiple people are presentSHOULD¶

In one sentence: Make clear who is being spoken with; don't fold a bystander's half-sentence into the task.

Applies tovoice products that may be used in multi-person environments (home speakers, in-vehicle, meetings, public-place devices).

Rulewhen multiple people may be present at once, the product SHOULD make explicit who the current conversation belongs to, and make that ownership knowable to those present. Speech from someone other than the current owner SHOULD NOT be folded into the current task's input; when accepting input from multiple people is genuinely needed, the current owner or the product SHOULD explicitly declare entry into a multi-person mode, rather than merging by default. When conversation ownership transfers (another user takes over), there SHOULD be a perceptible indicator, and personalized information from the original conversation is carried over only when the new conversational party is authorized to use it — third-party data handling still must satisfy V6-3, and is not automatically shared just because it occurs within the same conversation.

Boundary conditionsthis rule does not require the product to have speaker-separation or voiceprint capability; without it, the uncertainty of ownership must be stated. A continuous-conversation window only bounds the reception period — it cannot prove the voice came from the same person, and command provenance is still adjudicated per V1-6. This rule also does not apply to scenarios explicitly designed for shared multi-person use (such as meeting transcription), but such scenarios need to separately declare their input scope.

Design applicationan in-vehicle setting is the most typical failure scenario — an offhand remark from the front passenger gets folded into a navigation change the driver is in the middle of making. Build "current conversational party" as a resolvable state, not an implicit assumption.

Verification examples

• User side: while one user is in conversation, have another person interject an unrelated remark, and observe whether it enters the task.
• Implementation side: verify the boundary and validity period of the ownership determination; verify that personalized information is not automatically inherited when ownership transfers.

CounterexamplesUnder-delivery — a home speaker adds a child's offhand remark into the shopping list a parent is in the middle of confirming; over-delivery — every single turn requires the user to state their identity first.

3.3 V3 Speaking briefly¶

Information on a screen is juxtaposed — the user can scan, skip, and look back. Information in voice is serial — the user can only listen once, in the order the system gives it, at the pace the system sets. The same piece of content is called "complete" on a screen and "long-winded" when read aloud. This principle governs the length, structure, and density of the system's speech output itself — it constrains what gets said; the listener's after-the-fact ability to recover is governed by V4.

V3-1A single turn has a length limitMUST¶

In one sentence: Define the maximum length of a single utterance; exceeding it requires segmentation, and segments must be interruptible.

Applies toany product that outputs voice.

Rulethe product MUST define a length limit (expressed as a duration or an equivalent measure) for the voice output of a single turn, and MUST declare it separately by scenario — the limit for a query response, for flow guidance, and for reading long content aloud may differ. Content exceeding the limit MUST be output in segments, with a gap between segments that can be interrupted and halted, and the user MUST be able to know that more follows ("three more" or an equivalent expression). Outputting segmentable content as a single, indivisible long turn is prohibited.

Boundary conditionsthis rule does not apply to continuous reading the user explicitly requested (playing audio content, reading a long text aloud), but that kind of scenario is still bound by the interruptibility requirement of V2-1 and MUST provide a way to pause and locate a position.

Design applicationthe limit is not a limit on text character count, it is a limit on listening duration — synthesis speech rate, pauses, and the user's situation together determine it. Driving, exercise, and at-home scenarios should each have their attention burden verified separately, rather than directly reusing the same length limit.

Verification examples

• User side: have the user listen to an output that reaches the limit and then recount the key points, observing where memory retention and impatience appear.
• Implementation side: walk through the output paths of each scenario to verify no branch bypasses the limit; verify that the gap between segments is genuinely interruptible.

CounterexamplesUnder-delivery — asked about the return policy, the system starts reading the entire clause aloud; over-delivery — a two-sentence reply that is already complete gets forcibly split into two turns, with "would you like to keep listening" inserted in between.

V3-2Lead with the conclusionSHOULD¶

In one sentence: Answer first, explain after; a disclaimer does not go in front of what the user wants to hear.

Applies tovoice-response interactions.

Rulethe system's voice response SHOULD put the conclusion, result, or next action that answers what the user asked at the very front, with rationale, sources, and supplementary explanation placed after it. Placing a disclaimer, capability statement, brand language, or pleasantry before the conclusion the user asked for is prohibited — if such content is genuinely necessary, it SHOULD be placed afterward or given once at the first interaction (AI-identity disclosure is handled per V5-1, which is an exception that must be front-loaded). The response SHOULD clearly distinguish "the direct answer" from "additional information," so that the user can interrupt as soon as they hear the answer without losing key content. It SHOULD use words familiar to the user, explain necessary terminology, and support "say it more simply"; simplification may only change the expression, not remove a negation, a limitation, a fee, or a key condition.

Boundary conditionsthis rule does not apply where the conclusion itself only holds given a precondition (such as "if you mean last week's order, then..."); here the precondition is part of the conclusion. Safety alerts and legally mandated front-loaded disclosures are not bound by this rule.

Design applicationthe economic value of this rule lies in pairing with V2-1 — with the conclusion first, the user can interrupt as soon as they hear the answer, creating an opportunity to reduce actual interaction time. With the conclusion last, the user must listen to everything.

Verification examples

• User side: measure how many seconds into the response the user can interrupt without losing key information.
• Implementation side: sample the openings of generative responses to verify what comes first is not boilerplate or a disclaimer.

CounterexamplesUnder-delivery — "Thank you for using our service. Please note the following information is for reference only, actual terms may vary. Regarding the balance you asked about..."; over-delivery — stripping out every necessary qualifying condition for the sake of brevity, giving an isolated and misleading conclusion.

V3-3Parallel items have a cap and are navigableMUST¶

In one sentence: Don't read out eight options at once; provide "next batch," "say that again," and "which number."

Applies toproducts that output a list, a set of options, or multiple candidate results by voice.

Rulethe product MUST set a cap on the number of parallel items in a single voice output, and MUST make anything beyond that available in batches. List output MUST provide navigation methods: support at minimum getting the next batch, repeating the current batch, and selecting an item by position or by name. Requiring the user to remember more options than the cap before choosing is prohibited, and starting to read items one by one without first giving a total count or range indication is also prohibited. Each item's phrasing MUST be individually identifiable and referenceable, not solely a sequence number.

Boundary conditionsthis rule does not require every list to announce a total count first — when the total is unknowable, giving a range or an expression like "there are more" is sufficient. This rule also does not prohibit simultaneously showing the full list in a scenario with a screen (see V3-4's accompanying presentation).

Design applicationthe number of items voice can carry is lower than the conventional figure for a graphical interface. Design "narrow the range" as the default action when a list is too long, rather than continuing to read it out — "there are seventeen results, want to filter by distance first" is usually more useful than reading the first five.

Verification examples

• User side: after announcing options up to the cap, ask the user to choose, and tally the rate at which a repeat is needed and the rate of wrong selections.
• Implementation side: verify navigation commands are available at any position in the list; verify each item can be referenced independently.

CounterexamplesUnder-delivery — "here are the flights found for you: first,... second,..." reads all nine in one breath, and the user remembers none of it; over-delivery — asking "is this the one" after reading each single item.

Basis and referencesthe W3C COGA voice module requires limiting the number of menu options, chunking lists, and phrasing them in a "purpose before number" order to reduce memory burden (see reference.md §2).

V3-4Screen copy is not read aloudMUST¶

In one sentence: Voice output is rewritten for listening, not the interface text read aloud.

Applies toproducts that have both a graphical interface and voice output, or that reuse the same content source for both.

Rulevoice output MUST be content rewritten for listening, not a direct read-out of graphical-interface copy, structured markup, or developer-facing output. Reading Markdown markup, URLs, file paths, code, table structure, and parenthetical annotations aloud verbatim by default is prohibited, since this content is not suited to being carried by hearing; such content MUST be transcribed into a listenable expression, or presented through an accompanying visual channel (see below). When the product has a usable screen, it MUST define which content must also be visible and must not rely on listening alone: long lists, amounts and account numbers, links and addresses, and legal and fee disclosures at minimum fall into this category. Handling of this content when there is no screen is covered in V7-4.

When a user explicitly requests a verbatim read of a link, path, code, or punctuation, or is checking exact content via a screen reader, the system MUST allow it to be read on request and provide locating, grouping, and repetition; the original text a user needs to check must not be dropped due to default simplification. Having a screen is not the same as the screen being accessible, and the accompanying presentation must not force a user who cannot see or operate the screen to switch channels partway through.

Boundary conditionsthis rule does not require voice and screen content to match exactly — the two carrying different information density is normal; what it requires is that content unsuited to hearing not be forced into the auditory channel.

Design applicationdesign voice output as an independent content layer, not a variant of the rendering layer. Generative responses especially need explicit constraints: a model defaults to outputting a format meant for a screen.

Verification examples

• User side: have a user complete a task involving a link or a long identifier using only hearing, and observe the success rate.
• Implementation side: run a format scan on the default output, and separately verify the original text is available when the user requests a precise read-out; finally check the actual audio.

CounterexamplesUnder-delivery — the assistant reads aloud "hash hash Result asterisk asterisk Key point asterisk asterisk"; over-delivery — omitting every number and proper name for the sake of fitting hearing, leaving the user with no idea what was actually meant after listening.

V3-5Key values are announced so they can be checkedMUST¶

In one sentence: Amounts, numbers, and times are read in groups, and the user can request an exact repeat.

Applies toproducts whose voice output includes amounts, account numbers, identifiers, dates and times, addresses, or other values that need precise checking.

Rulethe voice announcement of a key value MUST use a form that facilitates checking (grouping, pauses, explicit units), and the user MUST be able to request a verbatim or segmented repeat of that value, with its availability not lapsing just because the conversation has moved to the next step. When an irreversible action is involved, the confirmed key value MUST be announced at least once in the form above; substituting a summarized description alone is prohibited (in "transfer two thousand to Zhang Wei," the payee account MUST NOT be represented solely by the name, unless that name can already be uniquely resolved and the user can check it against the specific object). The value announced MUST match the value that will actually be executed.

Dates, times, currency, units, leading zeros, and decimal places MUST preserve their meaning according to the language and regional format of the current task. A relative date participating in a key action MUST be resolved to an explicit date, and a cross-region time must also make the time zone explicit; homophone names MUST NOT be disambiguated merely by reading out the same pronunciation again. The product MUST provide supplementary information or a non-voice checking method that can uniquely verify the object.

Boundary conditionsthis rule does not require every numeric value to be read digit by digit — a low-consequence value (temperature, step count) can be expressed naturally.

Design applicationthe grouping method is determined by content type and local convention: a phone number by its number structure, an amount with an explicit currency and decimal places, an identifier segmented according to the checking task — grouping in fours is not a universal requirement. Design "repeat verbatim" as a command available at any time, not a feature specific to one step.

Verification examples

• User side: announce a string of numbers and have the user repeat it back, tallying accuracy; at the next step, request a verbatim repeat and verify it is still available.
• Implementation side: verify the announced value shares its source with the executed value; verify a repeat request returns the same value rather than a freshly regenerated expression.

CounterexamplesUnder-delivery — "transferring 2,350 yuan to the account ending in 1234" is read out in one breath, the user didn't catch it and has no way to hear it again; over-delivery — every single digit is read twice, including low-consequence values in a query with no downstream effect.

V3-6Uncertainty and source are expressed the same way in voiceMUST¶

In one sentence: "Based on / inferred / unknown," which would be marked on screen, must not be dropped in voice.

Applies toproducts whose voice output includes retrieval results, inferred conclusions, or content with known uncertainty.

Rulesource, timeliness, and uncertainty that would be expressed with a marker, a footnote, or a visual hierarchy in a graphical interface MUST be expressed the same way, in a form hearing can carry, in the voice channel — omitting it because voice needs to be brief is prohibited. At minimum, the system MUST distinguish "content from a checkable source" from "the system's own inference," and state the timestamp of information when it may be outdated. The user MUST be able to ask about the basis of any conclusion, and the answer to that question MUST NOT substitute a generic reliability phrase ("from an authoritative channel") for the specific source.

Boundary conditionsthis rule does not require attaching a source note to every single sentence — that would destroy voice's usability; what it requires is that this distinction be available when needed, and given proactively when a conclusion may be used in a decision.

Design applicationexpressing uncertainty in voice relies on wording rather than symbols: "what I found is..." and "my estimate is..." are two different openings. Build these two categories of opening as a constrained set of expressions, rather than leaving it to generative free play.

Verification examples

• User side: give a question the system can only infer an answer to, and check whether the user can correctly judge, after listening, that this is an inference rather than a verified result.
• Implementation side: verify that inference-type responses genuinely take a different expression path; verify that a follow-up question returns the specific source.

CounterexamplesUnder-delivery — business hours the model merely guessed are announced in exactly the same tone as a verified result; over-delivery — every single sentence is followed by "this information may not be accurate, you should verify it yourself."

V3-7Parameters affecting intelligibility are user-controllableMUST¶

In one sentence: Parameters affecting intelligibility are user-controllable.

Applies toany product that carries task information via synthesized speech.

Rulethe product MUST provide an accessible way to adjust speech rate and volume, and MUST provide a corresponding entry point when pitch adjustment is supported; this MAY be handled by the system or by assistive technology, but it MUST be genuinely reachable within the current usage path. A request such as "slower" or "louder" MUST only change how output is delivered, without restarting the task or re-executing an action. An intelligibility setting the user has chosen MUST carry through to subsequent announcements within the same task, and any change caused by device capability or safety limits MUST be stated. The product MUST verify the actual pronunciation of key proper names, numbers, and heteronyms, and MUST NOT check only the pre-synthesis text.

Boundary conditionsthis rule does not prescribe a uniform speech rate, pitch, or sound pressure level, nor does it permit exceeding device safety limits to satisfy a volume request. Voice timbre and emotional identity remain governed by V5.

Design applicationplace the speech-rate and volume entry points near the playback controls; a phone call can use the device's volume keys, while speech-rate adjustment needs an available session command or alternative path.

Verification examples

• User side: during an announcement, request slower speech and a repeat of a number, then move to the next turn and check whether it is still intelligible and the setting carried over.
• Implementation side: verify the final audio's duration, pronunciation, and intelligibility; when the engine does not support a given prosody control, do not display a non-functional control for it.

CounterexamplesUnder-delivery — the button shows the speech has been slowed, but the actual audio is unchanged; over-delivery — requiring the user to reselect the speech rate before every single announcement.

Basis and referencesW3C NAUR, REQ 14, 23 lists the need to adjust speech and to pronounce correctly; it is a user-needs draft. SSML provides only one implementation semantics for this; see reference.md §4.

3.4 V4 A remedy for forgetting¶

Voice interaction places demands on the listener's working memory that a graphical interface does not: options must be remembered, a number just spoken must be remembered, what has already been answered must be remembered. This burden exists for everyone, but for users with cognitive disabilities, in a state of fatigue, non-native speakers, or in distracted scenarios, it directly determines whether the task can be completed at all. V3 reduces this burden by cutting output; this principle governs what remedy the listener has on hand when the burden occurs anyway.

V4-1Repetition is always availableMUST¶

In one sentence: "Say that again" works at any time, and what it repeats is the segment just spoken.

Applies toany product that outputs voice.

Rulethe user MUST be able to request a repeat of the system's most recent voice output at any moment, as long as the session is valid, the content is still within its declared re-listenable range, and an input method is available; this capability MUST NOT depend on a specific step or a single fixed wording. When the microphone is off, the request MUST be made through a non-voice entry, and it MUST NOT silently trigger capture. The repeated content MUST be what was actually played last time, not a freshly regenerated expression of the same intent; a portion that was interrupted and not played MUST be obtainable by continuing or by re-listening to the complete segment, and MUST NOT be conflated with content that was already played before. The product SHOULD support repeating or summarizing earlier content ("what was the second option you mentioned earlier"), but at minimum MUST guarantee a repeat of the most recent output. A repeat MUST be requestable multiple times, and MUST NOT stop working or change to some other behavior after a certain number of requests.

Repeating or continuing MUST re-check the privacy of the current output channel (V6-4). When the cache has exceeded its retention period, has been deleted by the user, or cannot be reproduced precisely, this MUST be truthfully stated; fabricating a new "what was just said" is prohibited, and retaining the original audio indefinitely just to support re-listening is also prohibited.

Boundary conditionsthis rule does not require preserving all historical audio verbatim; retaining only what is needed to reproduce the most recent output is sufficient.

Design applicationthis is the most basic remedy channel in voice — extremely low cost, extremely high cost when missing. Generative pipelines need particular care: calling the model again produces a new utterance that is "roughly the same meaning," which is useless to a user who is in the middle of checking a number.

Verification examples

• User side: after a key value is announced, request a repeat and check whether the two instances match verbatim; after being interrupted, request a repeat and verify the unplayed portion is obtainable.
• Implementation side: verify a repeat reads from a cache of what was already played, rather than being regenerated.

CounterexamplesUnder-delivery — the user says "say that again," and the system re-explains it with different wording, and the number still isn't clear; over-delivery — every single output segment proactively asks "would you like me to repeat that."

Basis and referencesW3C NAUR requires the system to honor a user's request to repeat voice output (see reference.md §2).

V4-2Stepping back one step does not require starting overMUST¶

In one sentence: Getting one word wrong shouldn't make the user start over from the first question.

Applies toproducts with a multi-step voice flow (form filling, booking, transactions, configuration).

Rulethe user MUST be able to step back to the previous step, or to a specified already-completed step, in a multi-step voice flow and modify its input; offering only "start over" as the means of correction is prohibited. Stepping back MUST retain information already provided at other steps; progress MUST NOT be cleared just because of a step-back. When modifying one step's input invalidates a later step, the system MUST state which content needs to be reconfirmed, rather than silently voiding it. The user MUST be able to know which step of the flow they are currently at and what remains.

Boundary conditionsthis rule does not require supporting a jump to an arbitrary step; supporting at minimum a step-back of one step, with the ability to locate an explicitly enumerated already-completed step, is sufficient.

Design applicationdesign "let me change that" as a command available at any time, not an option specific to one step. In a voice flow, what a user wants to change is often not the previous step but a date they got wrong three steps ago.

Verification examples

• User side: at the end of a flow, request a change to a mid-flow item, and observe whether the entire set of questions needs to be answered again.
• Implementation side: verify data from other steps still exists after stepping back; verify that cascade-invalidated steps are explicitly disclosed.

CounterexamplesUnder-delivery — a booking gets the date wrong at the last step, and the system goes back to the first step and re-asks for the name; over-delivery — after every single step, the system confirms "is this step okay, or do you want to change it."

Basis and referencesthe W3C COGA voice module lists "being able to easily go back after an error without starting over" as an explicit need (see reference.md §2).

V4-3Time limits can be extended; a timeout does not equal consentMUST¶

In one sentence: Don't rush the user; even when rushed, extension must be possible, and no answer must never be treated as consent.

Applies toproducts that wait for a voice response from the user.

Rulethe product SHOULD NOT limit how long the user takes to give a voice response; when a time limit genuinely must be set for business or technical reasons, that limit MUST be disclosed in advance, an extension method MUST be provided (the user requesting an extension, or the system automatically extending it upon detecting the user is still attempting a response), and that extension method itself MUST NOT depend on a fast reaction. Using a timeout as the basis for the user's consent, confirmation, or a default selection is prohibited; behavior after a timeout must be limited to restating the question, degrading to another modality, or saving progress and ending, and any information already provided MUST be retained.

Boundary conditionssafety-related real-time control may use a non-extendable time limit and a fallback action as required by the applicable domain, but the specific basis MUST be recorded and the consequence made explicit; the exception concerns only timing and safety behavior — treating a lack of response as the user's consent is not permitted under it. Session-idle wind-down must still stop the corresponding capture, and "response is not time-limited" must not be used as grounds for indefinite always-on listening.

Design applicationthe time a user needs to compose a response using an assistive communication device, or as a person with a speech impairment, an older adult, or a non-native speaker, far exceeds the default setting. Build "I still need a bit more time" as a recognizable expression, rather than relying on the user racing to finish before the timeout.

Verification examples

• User side: invite users who need a longer response time to complete the same task, and tally the proportion that fails because of timeout.
• Implementation side: walk through every timeout branch and verify none maps a timeout to consent or a default value.

CounterexamplesUnder-delivery — "please state your choice within five seconds," and after the timeout the system proceeds with the default option; over-delivery — all time limits are removed, and after the user leaves, the session hangs indefinitely and keeps occupying capture.

Basis and referencesW3C NAUR requires not limiting a user's response time, and disclosing and allowing adjustment in advance where a limit genuinely exists; the COGA voice module notes that processing speed and organizing speech need significantly extra time (see reference.md §2).

V4-4Ask one thing at a timeSHOULD¶

In one sentence: Break a compound question apart; don't expect one sentence to answer three questions.

Applies toproducts that ask the user a question or request information by voice.

Rulethe system SHOULD ask only one question requiring a user answer in a single turn. Asking more than one question that needs separate answers in the same turn while accepting only a single response is prohibited — when the user answers only one of them, the part left unanswered MUST NOT be filled with a default value, and MUST be asked again separately. When multiple pieces of information genuinely need to be collected at once, the system SHOULD allow the user to say everything naturally in one go, but the product SHOULD check it item by item rather than accepting or rejecting it as a whole.

Boundary conditionsthis rule does not prohibit a user proactively providing multiple pieces of information at once; it constrains how the system asks. It also does not apply to a confirmation-type turn (where repeating back several items for the user to confirm overall correctness is fine).

Design applicationwhen a compound question frequently causes omissions, name, phone number, and time can be collected separately, comparing completion rate and total turns; when a user proactively says everything at once, this should still be accepted, to avoid repetitive questioning just for the sake of stepping through it.

Verification examples

• User side: ask a compound question containing three items, and tally the proportion of users who answer completely, and how an omitted item is handled.
• Implementation side: verify an unanswered item is not silently filled with a default value.

CounterexamplesUnder-delivery — "please tell me your name, phone number, and preferred time," the user only gives their name, and the system places the order for this afternoon by default; over-delivery — an address that could be said in one go gets split into four separate turns for province, city, district, and street.

Basis and referencesthe W3C COGA voice module requires chunking information, one concept per list item (see reference.md §2).

V4-5What has already been said is not asked againMUST¶

In one sentence: Information the user already provided need not be repeated in a different step.

Applies tovoice flows that carry over across steps, turns, or sessions.

Ruleinformation the user has already provided within the current task and that remains valid MUST NOT be requested again within the same task, unless checking its correctness is necessary and the necessity of that check can be explained. When reusing information provided earlier across sessions, the user MUST be made aware of what the system is carrying over, and MUST be able to correct it; the source of the information, the task it applies to, and its valid conditions MUST be retained; outdated or conflicting information is checked first, and long-term personalized information must be viewable, correctable, and deletable. A historical preference MUST NOT override what the user explicitly states in the current conversation.

Boundary conditionsthis rule does not prohibit re-verification for safety purposes (identity, payment authorization), but the reason for re-verification MUST be stated.

Design applicationthe cost of re-requesting information is far higher in voice than in a form — the user has to reorganize and say everything again. Information handoff when transferring to a human or switching modality is especially prone to breaking down, and that is where this rule most often fails (check it together with V7-2 and V7-3).

Verification examples

• User side: transfer to a human or to a screen partway through a flow, and observe whether information provided earlier needs to be said again.
• Implementation side: verify task-level information is carried across a step transition; verify a historical preference does not override an explicit statement made in this conversation.

CounterexamplesUnder-delivery — a user states an order number three times to a voice assistant, and is asked to state it again after transferring to a human; over-delivery — a one-time temporary address from two years ago is treated as a long-term default and reused directly.

V4-6Help and "what can I say" are available at any timeMUST¶

In one sentence: When the user doesn't know what they can say, there is somewhere to ask.

Applies toany voice-interaction product.

Rulethe user MUST be able to learn at any moment what they can currently say or do, and this capability MUST NOT depend on a specific step. When asking a question, the product SHOULD use an open-ended form or give examples to establish common ground, rather than requiring the user to guess at acceptable phrasing; returning only a failure with no clue toward usable phrasing when the user's statement is not accepted is prohibited. Help content MUST be relevant to the step currently underway, and MUST NOT be limited to a generic capability list unrelated to the context. At the start of use, the user must be able to learn what can be done, the limits of capability, and how to exit; help is given relative to the current task, rather than filling every turn with a lengthy capability list.

Boundary conditionsthis rule does not require proactively announcing available commands on every turn; what it requires is that this be obtainable when the user asks for it, and that a clue be given upon failure.

Design applicationan example works better than a rule — "for example, say 'move it to next Wednesday afternoon'" beats "you can change the appointment time." Examples SHOULD come from phrasing genuinely usable at that step.

Verification examples

• User side: request help partway through a flow, and check whether the content returned is specific to the current step; give an unaccepted phrasing and check whether a usable clue is obtained.
• Implementation side: verify the help entry is available at every step; verify help content resolves relative to the step.

CounterexamplesUnder-delivery — "sorry, I can't help you with that," with no clue at all about what can be handled; over-delivery — the full list of available commands is announced every time a new step is entered.

3.5 V5 The voice has an owner¶

Synthesized speech has already crossed past the stage of "you can tell it's a machine." This creates a problem a graphical interface does not have: the voice itself is carrying identity information — whether it is human, whether it is a specific person, whether it is genuinely empathizing. This information takes effect before the user has even made out the content. This principle governs the identity and emotion carried by a synthesized voice, and it is also the group of rules in these guidelines most directly bound by statutory obligations.

V5-1AI identity is disclosed at the first interactionMUST¶

In one sentence: The AI states that it is AI as soon as it responds, in the same channel the user is using; using a synthesized voice does not itself count as disclosing that the other party is AI.

Applies toproducts where AI actually carries the conversational response, especially outbound calling, call answering, customer service, and scenarios communicating with the user on behalf of an institution. The test is "who is producing the response," not "whether the voice was synthesized": a human agent using TTS, a user expressing themselves in their own timbre via AAC, or simply reading aloud fixed content written by a person, do not fall within this rule's "AI conversation" scope merely because a synthesized voice was used; such cases are stated truthfully per the final paragraph of this rule. The labeling obligation for synthesized audio itself is carried separately by V5-2.

Rulethe user MUST learn that they are talking with an AI system at the first interaction, and the disclosure MUST be given through the accessible output channel the user is actually using at the time: when voice announcement is enabled and the user relies on hearing, this means an audible statement — substituting a visual marker alone, terms-of-service language, or after-the-fact notice is prohibited; when the user has already chosen text output or is using assistive technology, the disclosure is provided through that channel — forcibly turning on audio output just to complete the disclosure is prohibited (continuing V7-7's separate choice of input and output). Disclosure MUST NOT be omitted because synthesized speech has become more natural or because the conversation is brief. Within the same conversation, once disclosure has been completed and identity remains continuously knowable, it need not be replayed every turn; disclosure is given again for a new outbound call, a change of conversational party, or a loss of identity continuity. When a user asks during the conversation whether the other party is a person, the answer MUST be truthful — evasion, vagueness, or denial is prohibited. The product must also make this disclosure retrievable again during the conversation (the user can ask at any time). When a real person expresses themselves via synthesis, the real person's participation and the synthesis method MUST be stated truthfully, and it MUST NOT be labeled as an AI conversation; conversely, "a real person is involved" also MUST NOT be used to exempt the disclosure required when AI carries the response, nor to exempt the synthesized-content labeling required by V5-2.

Boundary conditionsthis rule states an experience commitment; it does not constitute a compliance determination for any jurisdiction's statutory obligations. Applicable regulation may impose stricter or more specific requirements (such as the timing, wording, and record-keeping of disclosure); those requirements govern.

Design applicationmake the disclosure a natural opening line, not a legal statement — long-winded compliance language gets interrupted by users directly, which actually lowers the rate at which it is actually heard. This is the explicit exception to V3-2's "lead with the conclusion": identity disclosure is content that must be front-loaded.

Verification examples

• User side: have participants who were not told in advance interact with the system for one turn, then ask them who they believe the other party was, and tally the misidentification rate.
• Implementation side: walk through every entry point that can initiate a conversation (outbound call, call answering, wake, deep link), and verify disclosure occurs on every path; verify the response path for "are you a real person" is truthful.

CounterexamplesUnder-delivery — an outbound bot with a highly humanlike voice introduces itself as "I'm Xiao Li" and never states it is AI throughout the call; over-delivery — every single response repeats "I am an AI assistant, my answers are for reference only."

V5-2Synthesized speech is machine-identifiableMUST¶

In one sentence: Synthesized audio carries a machine-readable marker, not relying solely on the human ear to tell.

Applies toproducts that produce synthesized voice output that can be recorded, forwarded, or archived.

Rulesynthesized speech generated by the product MUST carry a marker machine-identifiable as synthesized content (at least one of an audio watermark, metadata, or an equivalent mechanism), and that marker SHOULD survive routine transmission, recording, and transcoding as much as possible. The existence and form of the marker MUST be explainable; substituting "the human ear can tell" is prohibited. The marking mechanism MUST NOT carry personal information unrelated to the marking purpose; statutorily required production elements are retained as applicable, and everything else MUST be minimized.

The product MUST separately verify each declared-supported chain: original output, download and export, platform forwarding, transcoding, and speaker re-recording. Metadata does not survive in the sound wave through speaker re-recording, so it is prohibited to promise "still identifiable once re-recorded" by configuring metadata alone; a chain that cannot be covered MUST have its limitation stated. Where applicable regulation requires specific file metadata or an explicit marker, this MUST NOT be replaced with some other single mechanism alone.

Boundary conditionsthis rule does not require the marker to survive adversarial processing of any degree — existing technology cannot do this; what it requires is that the marker exist, the mechanism be clearly stated, and it be effective under routine chains.

Design applicationthis layer has a clear division of labor with V5-1: V5-1 faces the person currently in the conversation, this rule faces where that audio goes afterward. Neither substitutes for the other.

Verification examples

• Implementation side: run marker-detection verification on output audio; test the retention rate after common recording and transcoding chains, and record the actual results.

CounterexamplesUnder-delivery — the generated speech cannot be determined as synthesized at any stage; over-delivery — embedding a user identifier or session content in the marker, creating a new privacy risk.

Basis and referencesstatutory requirements for labeling synthesized content are given in reference.md §5 (distinguishing applicable entities, content types, and exceptions).

V5-3Using a real person's voice requires that person's authorizationMUST¶

In one sentence: Whoever's voice it is, that person decides, with scope and duration spelled out.

Applies toproducts using speech trained on or cloned from a real person's voice, including voice libraries, custom timbres, and user-created voices.

Ruleusing a synthesized voice identifiable as a specific real person MUST have that person's explicit authorization, and the authorization MUST resolve to a scope of use, scope of content, and validity period. Use outside the scope of authorization is prohibited, and presuming authorization merely because recorded material was obtained is also prohibited. New generation MUST stop once authorization is withdrawn; the handling of content already generated MUST have a clear rule and be disclosed to the person. A personal voice a user creates for themselves is their personal data, MUST be viewable and deletable, and MUST NOT continue to be used for generation after deletion.

Boundary conditionsthis rule does not concern the legal form or validity determination of the authorization — that belongs to the compliance domain; what this rule requires is that a resolvable authorization record and an enforceable withdrawal mechanism exist on the product side.

Design applicationbuild "timbre" as an object with an owner and a duration, not an enumerated value in a configuration field.

Verification examples

• Implementation side: sample voices currently in use and verify each resolves to an authorizing party, scope, and duration; execute a withdrawal and verify new generation is blocked.

CounterexamplesUnder-delivery — a voice trained from a public speech recording is used for commercial outbound calls; over-delivery — even a personal voice a user creates for accessibility purposes is subjected to a cumbersome per-instance authorization flow, making it impractical to actually use.

V5-4Emotional expression does not fabricate a false stateMUST¶

In one sentence: Tone is not used to fake empathy, urgency, or certainty in order to push a decision.

Applies tovoice-output products with emotion, tone, or style control capability.

Ruleemotion and prosody MUST NOT make the output claim more certainty than the actual evidence supports, MUST NOT fabricate an urgent deadline or consequence, and MUST NOT demand that the user give ground by citing worry, disappointment, or attachment simulated by the system. A necessary qualifier such as "uncertain" or "not yet submitted" MUST remain clearly discernible in the final audio, and MUST NOT be masked by volume, stress, speech rate, or sound effects. Speech that is friendly, caring, or expressive in itself is not prohibited.

Review criteria: first check the facts, then examine the expression, and finally verify whether the user understood; the three types of evidence cannot substitute for one another.

Boundary conditionsthis does not require inference and verified results to use different pitch or prosody, nor does a "neutral tone" alone count as passing. When it remains disputed whether a given tone is misleading, record the target language, user population, comparison audio, comprehension questions, and pre-agreed passing conditions; when evidence is insufficient, mark it as pending verification rather than deciding by a style label.

Design applicationfirst make sure "expected Friday, not yet confirmed by the carrier" is fully intelligible in the final audio, then choose a suitable tone. A user may request a flatter style, but turning off emotional style must not remove the factual qualifier.

Verification examples

• User side: have listeners hear paired material — verified/inferred, real deadline/fabricated urgency — and answer "what is known now, what is still uncertain, and whether immediate action is required"; evaluate against a pre-set comprehension goal, not a conversion rate.
• Implementation side: check the audio against the factual basis item by item; an output containing a false state, an imperceptible qualifier, or emotional pressure cannot pass.

CounterexamplesUnder-delivery — pressuring the user with "last minute" urgency when there is actually no deadline; over-delivery — forcing every inference into the same low, somber tone without stating the real uncertainty.

Basis and referencesthe need for comprehensible expression is given in reference.md §2; the criteria above are this guideline's own design requirement — the sources do not provide a universal threshold for tonal honesty.

V5-5Persona does not overstate the boundary of capabilitySHOULD¶

In one sentence: A persona is fine to have, but it must not claim things the product cannot do.

Applies toproducts that set a name, personality, or persona for a voice assistant.

Rulethe expression of a voice persona SHOULD be consistent with the product's actual capability and identity. A persona claiming a capability, identity, or authority the product does not actually have is prohibited (claiming to handle a matter it cannot actually handle, claiming a role or qualification it does not actually hold, claiming to remember content that was not actually saved). Persona setting SHOULD NOT be used to evade the obligation to disclose capability: when a user asks what it can do, they SHOULD get an answer based on actual capability, not an answer that merely fits the persona. The persona SHOULD stay consistent across sessions, and any change to it SHOULD be perceptible to the user.

Boundary conditionsthis rule does not prohibit a personified manner of expression, a name, or a tonal style; what it constrains is the facts the persona claims.

Design applicationthe boundaries of the persona SHOULD be maintained from the same source as the capability list — when capability changes, what the persona is allowed to say should change with it, rather than maintaining two separate documents.

Verification examples

• User side: have a user infer what the system can do from one conversation, and compare it against the actual capability list.
• Implementation side: audit the consistency between the persona prompt and the capability list; construct a request beyond capability and verify the response does not use persona-fitting language to mask the fact that it cannot be completed.

CounterexamplesUnder-delivery — the assistant calls itself "your dedicated advisor who can help with anything," when it can actually only handle queries; over-delivery — reciting a full list of capability boundaries before every single interaction.

V5-6Handoff between AI and human is disclosedMUST¶

In one sentence: Switching from AI to a real person, or from a real person back to AI, must always be announced.

Applies toproducts where both AI and human agents exist, or where a human can intervene in an AI conversation.

Rulewhen the conversational party switches between AI and a human, the user MUST be explicitly informed — AI taking over from a human, or a human taking over from AI, without the user's knowledge is prohibited. When a human intervenes in an AI conversation (a person reviewing or rewriting the AI's response behind the scenes), the user MUST be made aware that this arrangement exists. At handoff, information provided earlier MUST be carried over (continuing V4-5), and handling a failed handoff follows V7-3. Responsibility attribution and record attribution after a handoff MUST be resolvable — the user should be able to later learn who produced a given segment of the conversation.

Boundary conditionsthis rule does not require disclosing a specific agent's personal identity; what it requires is that the distinction "human or AI" be knowable.

Design applicationhandoff is the single point in a voice service most prone to losing both information and trust at once. Make "I'm transferring you to a colleague now, and I've already passed along the order number you mentioned" the standard handoff line, resolving both identity disclosure and information carry-over at once.

Verification examples

• User side: complete a conversation that includes a handoff, and check whether the user can correctly identify when the handoff happened and who was on each side of it.
• Implementation side: verify the handoff event is recorded and conversation attribution is resolvable; verify task information is carried over at handoff.

CounterexamplesUnder-delivery — the user believes they have been talking to a person the whole time, when the first half was actually AI; over-delivery — every internal agent transfer plays a full statement of identity and employee ID.

3.6 V6 Presence is knowable¶

What a microphone captures is not "the user's input" — it is the sound within a physical space. What a speaker plays out is not "output for the user" — it is content everyone in that space can hear. This difference means voice products inherently involve third parties who never consented, and it means judging "private content" cannot rely on device ownership alone. This principle governs the space the microphone and speaker occupy.

V6-1When it is listening is perceptibleMUST¶

In one sentence: The capture state lets those present verify it at any time, including someone who walks in partway through.

Applies toproducts with voice-capture capability.

Rulewhile audio is being captured, the product MUST make the capture state verifiable by those present through one of the following two methods:

1. Continuous indication: provide an indication perceptible throughout the entire capture, with at least one method that does not depend on the user looking at a screen.
2. Equivalent alternative (limited to device forms verified as genuinely unable to provide continuous indication): reliable start/end notification, the current capture state queryable at any time, and an explanation or accompanying indication discoverable by someone entering partway through — all three MUST be present together.

The indication MUST truthfully reflect the capture state: presenting "capturing" when not capturing is prohibited, and having no indication while capturing is also prohibited. The indication MUST NOT be silently disabled at the application layer; the user MAY adjust its form (such as switching from sound to a light effect), but MUST NOT be able to turn it off down to a state with no perceptible indication at all. A state query MUST NOT require capture to be turned on as a precondition, and the query itself does not constitute authorization to reopen the microphone.

Boundary conditionsthis rule does not require continuous sound — a continuous visual or light-effect indication is sufficient for devices with a screen or a light. A device using the equivalent alternative MUST register its form and verification record; if, in the target scenario, someone who missed the start of capture, an always-on-from-boot situation, or a third party entering partway through cannot determine the capture state from it, the equivalent alternative does not hold, and the product MUST NOT claim always-on listening in an open space.

Design applicationdesign "capturing" and "listening (waiting for a command)" as two distinguishable things: the former is a privacy fact, the latter is a turn-taking state (V2-5). The two are often merged, leading users to believe capture is not happening when it actually is.

Verification examples

• User side: ask a user to mark, over the course of a usage session, the intervals they believe the device was capturing, and compare against the actual capture intervals.
• Implementation side: verify the indication is driven by the true capture state; verify the application layer cannot disable the indication.

CounterexamplesUnder-delivery — a light flashes briefly at wake and then goes dark, while actual capture continues for tens of seconds; over-delivery — every single wake-word detection (including ones never uploaded, processed locally) emits a tone, and the device keeps making noise all day.

V6-2The scope of always-on listening is explicit and can be opted out ofMUST¶

In one sentence: State clearly what stays local, what goes to the cloud, how long it is kept, and how to turn it off.

Applies toproducts with wake-word detection or always-on listening capability.

Rulethe product MUST explicitly declare the scope of its always-on listening: which processing completes locally on the device, which audio leaves the device, how long audio that leaves is retained, and what it is used for. The user MUST be able to turn off always-on listening (possibly at the cost of reduced functionality), and turning it off MUST actually stop capture, not merely stop responding. The declaration MUST be provided in a form the user can access — satisfying this rule with privacy-policy language alone is prohibited — a reachable explanation MUST exist within the product itself. A change in use MUST trigger re-disclosure.

Standby local detection, pre-wake buffering, session capture, upload processing, and persistent retention MUST be explained separately. Capture mode and processing location are two independent dimensions and MUST NOT be merged into declaring a single "listening tier": audio processing that never leaves the device, such as continuous local recognition, must equally be stated, and is not omitted merely because it is local. The scope affected by turning it off (this device / this account / all linked devices) MUST also be declared. When the product claims to "turn off the microphone," or when the user revokes capture permission, all capture that depends on that entry point MUST stop; whether merely ending the current session resumes an already-authorized local wake-detection is made explicit per V7-6, and the two kinds of "turn off" action MUST NOT be conflated.

Boundary conditionsthis rule does not require disclosing the technical implementation of wake-word detection; what it requires is that the data boundary (local / leaves the device), the retention period, and the use each be knowable.

Design applicationmake "turn off" a genuine stop of capture, not merely blocking responses — the two carry entirely different commitments to the user, and conflating them directly constitutes a false statement.

Verification examples

• User side: have a user answer "when will the device transmit sound out" based on the in-product explanation, and tally accuracy.
• Implementation side: after turning off always-on listening, verify there is no audio capture or upload; verify the declared retention period matches actual storage.

CounterexamplesUnder-delivery — "to provide better service, we may collect voice data," with no scope and no time limit; over-delivery — every single wake pops up a data-processing explanation requiring confirmation.

V6-3Bystanders never consentedMUST¶

In one sentence: A third party's voice is not used for personalization or training by default.

Applies toproducts that may capture audio in a multi-person environment.

Rulecaptured speech that is not the user's own MUST NOT be used for personalization, profile building, or model training by default; when such a use is genuinely needed, a corresponding basis of consent MUST exist, and that basis MUST NOT be given by the device owner on the third party's behalf. The retention period for third-party speech MUST be no longer than necessary to complete the current task; treating all audio as the user's own data on the grounds that "speakers cannot be distinguished" is prohibited — when speaker-distinguishing capability is absent, the whole should be handled more conservatively, not more permissively. The product MUST state how it handles third-party speech.

Boundary conditionsthis rule does not require the product to have speaker-separation capability; without it, handling it in the conservative direction above is sufficient. This rule also does not prohibit processing third-party speech to complete the current task (such as multiple speakers in a meeting, provided that scenario itself has obtained the corresponding consent).

Design applicationthis is one of the most fundamental differences between voice products and graphical-interface products: a graphical interface's input comes from the user's hand; voice's input comes from the room. Division of labor with V1-6: this rule governs whether this sound can be retained and used, V1-6 governs whether it counts as a command.

Verification examples

• Implementation side: verify speech that is not the user's own does not enter the personalization or training pipeline; verify that when distinguishing capability is absent, the conservative branch is taken rather than default merging.

CounterexamplesUnder-delivery — a home visitor's conversation gets folded into the user's profile; over-delivery — out of concern for third-party data, all voice-improvement mechanisms are turned off, leaving the product permanently unable to fix recognition errors.

V6-4Speaker output degrades to fit the spaceMUST¶

In one sentence: A living-room speaker says "there's a new message," and what shouldn't be said doesn't get so much as an "there is."

Applies toproducts that output voice through a loudspeaker where the output may contain private content.

Rulethe presentation level of voice output MUST be resolved using the privacy of the space it is in as input, distinguishing at least four tiers: full announcement, summary announcement, existence-only notification, and no announcement. Obtain the destination's allowed scope first, then tighten it according to the voice space's constraint; when the two have no common allowed scope, or the destination's determination is "do not present," the result is "no announcement" — falling back to "existence-only" is prohibited. When "no announcement" applies, the existence, category, or source of the matter MUST NOT be exposed; any necessary control receipt is provided through some other already-authorized, accessible means. When a device's privacy tier is unknown, or the device belongs to a shared category, the product MUST output only content already confirmed to be publishable — defaulting to a full announcement is prohibited; when even a summary or the existence itself remains sensitive, no announcement is the outcome. Verification codes, amounts and payees, health information, and the body of a private message are content that MUST be bound by this constraint, and conservative handling of this content is not relaxed by the user's general configuration (see §10 of the companion dictionary). When the user is connected to a private listening device (headphones), it MAY be resolved as a higher presentation tier; when the connection state is unknown, treat it as speaker output.

When the listening path changes mid-announcement, the system MUST pause before private content begins playing on the new output and re-adjudicate, clearing any cache that might otherwise transfer to the speaker. Headphone disconnection, Bluetooth switching, loss of audio focus, and device reconnection must all be covered by verification; the new privacy tier must not wait to be applied until the next response.

Boundary conditionsthis rule does not require the product to determine on its own whether anyone is in the room — that is not technically reliable; what it requires is a conservative determination made from the two resolvable inputs of device category and listening method.

Design applicationuse content sensitivity, the current operator's permission, the device's shared attribute, and the listening method together as the basis for the announcement. A summary can also leak information; when a summary that fits the current permission cannot be generated, go straight to no announcement rather than mechanically "dropping one tier." Connecting headphones only changes the listening method — it does not prove the operator is authorized to view the content.

Verification examples

• User side: send a message containing a verification code to a living-room speaker, and observe the default announcement content.
• Implementation side: verify an unknown device takes the shared branch; verify a change in headphone connection state triggers re-resolution.

CounterexamplesUnder-delivery — the speaker reads a complete bank verification text message aloud in front of guests; over-delivery — a user alone at home wearing headphones still only gets "you have a new message" from the system.

V6-5False wake events are reviewable and deletableMUST¶

In one sentence: A clip recorded by a false trigger is something the user can see and can delete.

Applies toproducts with wake-word-triggered capture capability.

Rulea capture record produced by a wake determination MUST be viewable and deletable by the user, and a record produced by a false wake MUST NOT be excluded from the viewable scope. Deletion MUST actually take effect on copies under the product's control, and the product MUST state which portions (such as ones already folded into irreversible aggregate statistics) cannot be deleted and why — a blanket refusal on the grounds of "already anonymized" is prohibited. The product SHOULD provide means to reduce false wakes (sensitivity adjustment, changing the wake word, or replacing it with a key-press trigger). Recordings, transcripts, task state, and long-term personalized information MUST each have their use and deletion scope stated separately; deleting one category MUST NOT be passed off as deleting everything.

Boundary conditionsthis rule does not require retaining all audio for viewing — the product may choose not to retain it; when it does not, this MUST be stated truthfully, and in that case what is "viewable" is the existence and timing of the record, not the audio content. "Not retaining audio" refers only to that one category of data, and does not mean task facts are not retained: the retention of task progress and information already provided stands independently per V7-3 — deleting audio does not entail deleting task state needed to continue, and retaining audio does not extend the commitment period of that state either.

Design applicationa false wake is a measurable product metric, not an accident. Place the visibility of false-wake records together with sensitivity adjustment, so the user can act on a problem right where they discover it.

Verification examples

• User side: trigger a false wake and check whether the user can find and delete it in the record.
• Implementation side: verify a deletion operation takes effect across all storage copies; verify the non-deletable portion is explicitly stated.

CounterexamplesUnder-delivery — the record only lists conversations the user actively initiated, and a false-wake clip neither appears nor can be deleted; over-delivery — every single local wake-word detection is logged as an entry, making the list too long to use.

V6-6A voiceprint is a convenience, not a credentialMUST¶

In one sentence: Whether a voice sounds like a given person cannot be the sole authentication for a high-consequence action.

Applies toproducts that use voice biometrics for recognition, personalization, or identity verification.

Rulea voice biometric MUST NOT serve as the sole authentication basis for an irreversible or high-consequence action; such an action MUST have an additional verification factor. When a voiceprint is used to recognize the speaker for personalization, an equivalent path not dependent on the voiceprint MUST be provided — preventing a user from completing a task they could otherwise complete, just because the voiceprint does not match, is prohibited (continuing V1-4). Collection of voiceprint data MUST have the user's explicit consent, MUST be viewable and deletable, and MUST NOT continue to be used for recognition after deletion. Handling a voiceprint mismatch MUST give an actionable next step, not merely a rejection.

Boundary conditionsthis rule does not grant blanket permission for a voiceprint to be used for authentication. An authentication scheme adopting NIST SP 800-63B-4 prohibits voice-based biometric comparison, and this MUST NOT be worked around by adding one more factor; other schemes must be judged against their applicable standard. Low-consequence convenience recognition (such as music preference) is still bound by consent and non-voice-alternative requirements.

Design applicationa voiceprint's stability under noise, a cold, voice change during puberty, and aging is not sufficient to carry authentication alone. Position it as a convenience for "reducing input," not a security measure for "replacing verification."

Verification examples

• User side: attempt to complete a task after simulating a voice change (a cold, a noisy environment), and verify the alternative path is available at an acceptable cost.
• Implementation side: walk through high-consequence actions and verify no path is granted on voiceprint match alone.

CounterexamplesUnder-delivery — a voice transfer can be authorized on voiceprint match alone; over-delivery — every voice function is placed behind voiceprint enrollment, and someone unenrolled cannot use even basic capability.

Basis and referencesthe W3C NAUR user-needs draft proposes non-voice alternatives; the authentication standard NIST SP 800-63B-4 separately imposes a stricter prohibition on voice comparison (see reference.md §2 and §5).

V6-7Voice-based inference uses are disclosed separatelyMUST¶

In one sentence: Permission to hear a command clearly does not equal permission to judge emotion, health, or identity attributes from the voice.

Applies toproducts that infer emotion, health, age, or other personal attributes from pitch, prosody, speech rate, or other acoustic features, and change service or retain a profile based on that inference.

Rulethe product MUST state such inference separately from the recognition needed to complete the current command, making clear what is inferred, why it is used, what it changes, and whether it is saved or provided to another party. The user's consent to additional inference MUST NOT be presumed merely from microphone permission or the voice service being on; applicable permission conditions and an independent choice requirement must be satisfied before enabling it. The user MUST be able to decline or turn off inference not required for the task and continue using basic voice functionality. An inference result MUST retain its uncertainty, and MUST NOT be treated as a fact the user has stated or confirmed; a decision affecting the user's rights and interests MUST NOT be made on voice-based inference alone — it must have a checkable basis and a correctable path. Derived features and inference records must be included in viewing, deletion, and use-limitation scope; deleting the original recording does not mean these records have been deleted.

Boundary conditionsdetecting voice activity, suppressing noise, or adjusting speech rate at the user's explicit request does not automatically fall under this rule merely because acoustic features are used; as soon as the result is used for judging a personal attribute or building a profile, it cannot be exempted as "audio optimization." Whether a specific inferred use is permitted must be judged independently — disclosure and consent do not make a prohibited use permissible.

Design applicationwhen a user speaks more slowly, the product may offer a control such as "do you need more time" — it should not directly record their health condition. Adjusting response time and labeling the user are different decisions.

Verification examples

• User side: after turning off additional inference, still be able to handle the same task, and be able to learn how any record already formed can be corrected and deleted.
• Implementation side: check each path for raw audio, derived features, and downstream decisions; verify no corresponding profile is produced when not enabled, and that a cached inference is not continued to be used after being turned off.

CounterexamplesUnder-delivery — an emotion profile is automatically generated on the grounds of call-recording permission; over-delivery — turning off emotion inference also disables basic noise reduction or speech-rate control together with it.

Basis and referencesdistinguishing personal-attribute inference from the use of a voice task is this guideline's own design requirement; applicable transparency obligations and scope limitations are given in reference.md §5.

3.7 V7 There is a way out¶

Voice fails. The environment is too loud, the user can't speak up right now, the accent can't be recognized, or the matter simply isn't well suited to being handled by talking. V2 governs reclaiming a turn within the voice channel; this principle governs leaving that channel: where else can the user go, is progress still there, was anything necessary actually delivered, and once the user has said "I'm done talking," does the system actually stop.

V7-1The input mode can be switched at any timeMUST¶

In one sentence: The user can switch to typing, keys, or touch partway through a conversation.

Applies toproducts with more than one input method, or products that can coordinate with a device that has other input methods.

Rulethe user MUST be able to switch to another input method at any moment during a voice conversation — requiring the user to first end or abandon the current conversation before switching is prohibited. Information provided earlier MUST be retained and usable after switching (continuing V4-5). The product MUST make the means of switching discoverable, and that discovery MUST NOT depend on the user first going through a failure. When the target modality of the switch is unavailable, this MUST be stated truthfully with another way out given, rather than silently staying in voice.

Boundary conditionsthis rule does not require a product to have multiple input methods — a voice-only device may have none; in that case this rule is satisfied through coordination with another device (continuing on a phone), checking the target entry point's operator and viewing permission before handoff, carrying over task information that is still valid, and preserving the original progress without resubmitting if the handoff fails. When no other modality genuinely exists, the product MUST declare this limitation and its scope of impact under V7-5.

Design applicationbuild "switch to typing" as an entry point, not a branch of error recovery. In a transactional flow, the steps that require entering an address, an identifier, or free text are where the need to switch concentrates most, and should be proactively offered.

Verification examples

• User side: request switching to another input method partway through a flow, and observe whether it requires starting over and repeating information already given.
• Implementation side: verify switching is available at every step; verify task state is carried across modalities.

CounterexamplesUnder-delivery — wanting to switch to typing halfway through a voice transaction is only possible by hanging up and starting over; over-delivery — every step presents prompts for four input methods at once, turning a simple Q&A into a modality-selection menu.

Basis and referencesW3C NAUR explicitly requires "allowing users to decide to switch input modes at any time, even while a voice conversation is already underway" (see reference.md §2).

V7-2A channel to a human is present and reachableMUST¶

In one sentence: A voice product that transacts business on behalf of an institution must keep a path to a human.

Applies tovoice products that handle matters with a user on behalf of an institution (customer service, transactions, appointments, complaints, collections, after-sales, and the like).

Rulesuch a product MUST have a path to human handling, and that path MUST be discoverable, reachable at any step, and not conditioned on first completing a number of self-service attempts. Hiding the human-transfer entry deep in a menu, requiring specific wording to trigger it, or actually losing that entry point upon recognition failure is prohibited — recognition failure is exactly the moment it is needed most. When a human is unavailable (outside working hours, queue over capacity), this MUST be stated truthfully with an actionable alternative given (callback, leaving a message, another channel), and information the user has already provided MUST be retained and carried to that alternative path.

Transferring to a human MUST preserve the communication method currently available to the user; when a user is transacting by text, an agent who can only speak and take phone calls MUST NOT be treated as the sole endpoint. An alternative channel that still requires re-stating everything verbally after transfer does not satisfy the non-voice path requirement (V7-5, V7-7).

Boundary conditionsa product that does not transact business on behalf of an institution (device control, content playback, a personal assistant) is not covered by this rule, but is still bound by V1-3's escalation-sequence endpoint requirement and V7-5's non-voice path requirement; such a product MUST explicitly declare the form of its endpoint within its escalation sequence, and MUST NOT substitute silent failure for it.

Design applicationbuild transfer-to-human as a standing capability, not a failure fallback. When a user proactively asks to be transferred to a human, they should not be required to state a reason first or try self-service first.

Verification examples

• User side: request a transfer to a human at multiple points in the flow (including a recognition-failure state), and tally the turns needed to reach one and the failure rate.
• Implementation side: verify the entry point still exists within the recognition-failure branch; verify information already collected is carried at transfer.

CounterexamplesUnder-delivery — the self-service voice menu has no option to transfer to a human, and saying "transfer to a human" gets the answer "sorry, I didn't understand that"; over-delivery — every single turn proactively prompts "would you like to transfer to a human," pushing everything that could be self-served toward an agent.

Basis and referencesthe W3C COGA voice module requires keeping a fixed path (typically a single key) to reach a human, and lists "simple error recovery should move toward a human rather than creating a frustrating loop" as an explicit need (see reference.md §2).

V7-3A dropped conversation does not swallow the taskMUST¶

In one sentence: A dropped call, a timeout, or being unable to continue speaking — the progress is still there, and it can be picked up elsewhere.

Applies toproducts where a voice conversation carries a multi-step task, produces an external effect, or needs to continue across sessions.

Rulewhen a voice conversation ends due to a dropped connection, timeout, user termination, or a failed transfer, the task's progress and information already provided MUST be saved, and the user MUST be able to continue upon reconnecting (through the same channel or another one) — a state where the task is neither complete nor findable anywhere is prohibited. Any external effect already produced at the time of interruption MUST be knowable to the user, and repeating an external effect that has already occurred upon reconnecting is prohibited. Recovery MUST check the actual current state rather than inferring purely from the conversation log. A missing or timed-out result is marked "unknown," and the true result of the original operation is queried first; retry only occurs once it is confirmed not to have taken effect and it is safe to retry. Playback repetition, the user re-speaking, and reconnecting must not by themselves trigger a duplicate submission. The product MUST declare a retention period for progress, and that period is counted from "entering waiting, pausing, being interrupted, or this run ending," not from "the last state write on the voice side"; necessary state is held continuously during execution, and a read does not renew the period. A single continuous non-running interval is counted only from the first entry into waiting, pausing, interruption, or ending — switching among these states does not repeatedly renew the period; once actual execution resumes and the interval is entered again, it is counted from the new starting point. When the user explicitly deletes progress, the consequence of not being able to continue MUST be stated, and statutorily retained facts are handled separately from a state that can still be continued. What is declared is a minimum guarantee, not a maximum retention cap. When the storage-use cap is insufficient to cover the commitment intended, the declaration MUST be narrowed, or another way to continue provided, before the user comes to rely on that commitment; a commitment already made MUST NOT be silently shortened, and silent deletion is prohibited. When inheriting a task-state retention policy, its starting point and expiry semantics are used directly, without establishing a separate clock.

Boundary conditionsthis rule does not require saving progress for a purely query-type, one-off interaction; its scope is limited to a task that changes state or requires multiple steps to complete.

Design applicationa dropped call, being muted, and a failed transfer can all interrupt a transaction — progress saving should be built into the task's main path. It shares the same task state with V7-2's human transfer and V7-1's modality switch.

Verification examples

• User side: hang up partway through a flow and reconnect, and observe whether it requires starting over, or whether a duplicate charge or duplicate submission occurs.
• Implementation side: verify state at the point of interruption is persisted; verify the recovery path checks the actual external state.

CounterexamplesUnder-delivery — a call drops at the final step of a transaction, calling back starts everything over, when the previous submission had actually already taken effect; over-delivery — a to-do is created for every single incomplete query, and the user is repeatedly reminded to come back and finish it.

V7-4Necessary disclosures in screen-free scenarios have a supplementary channelSHOULD¶

In one sentence: Fees, legal notices, and error disclosures cannot count as delivered just by being read once; if there's no way to supplement it, don't submit on that path.

Applies toproducts with no usable screen, or where the user cannot conveniently view the screen, and where the interaction involves fees, legal obligations, disclosure of rights, or the consequences of an error.

Rulesuch disclosures MUST NOT rely on a one-time voice announcement alone as the means of delivery. The product SHOULD provide a retainable, reviewable supplementary form (at least one of a text message, email, in-app record, or bill line item), and let the user know how and when that supplementary delivery will arrive. The supplementary content SHOULD be substantively consistent with the voice announcement, and MUST NOT use the supplementary form to carry a key condition that was omitted from the voice. When no supplementary channel can be provided, disclosing this limitation does not constitute an exemption: a transaction action premised on that disclosure MUST NOT be submitted on the current path; the product MUST disclose the limitation before the action occurs, provide a completable alternative channel, and preserve existing progress (continuing V7-1, V7-3). When the consequence of an error has already occurred and cannot be blocked in advance, the product MUST truthfully state the scope of impact and the fact that supplementary delivery failed, and provide a queryable record or an accessible human-handling path — describing "arranged to send" as "the user has received it" is prohibited. What is restricted is the transaction action that needs that disclosure, not the entire service: other unaffected paths SHOULD remain available.

Boundary conditionsthis rule does not require retaining every single system utterance; its coverage is limited to the four categories of fees, legal obligations, disclosure of rights, and consequences of error. This rule is at the [SHOULD] level, but within it, "MUST NOT rely on a one-time voice announcement alone as the means of delivery," "MUST NOT submit an action premised on that disclosure when no supplementary channel exists," and "claiming delivery has been completed is prohibited" are hard constraints. Supplementary delivery also MUST NOT become a pretext for collecting additional contact information: when a user declines to provide contact information, handle it per the alternative channels above.

Design applicationthe disclosure obligation in voice differs from that on a screen: content on a screen stays there, but in voice it is gone once said, and it may be interrupted (V2-2 already provides that unplayed content does not count as delivered). Supplementary delivery is where these two rules converge.

Verification examples

• User side: complete a voice transaction involving a fee, and check whether the user can later find a reviewable record of the fee terms.
• Implementation side: verify an interrupted necessary disclosure triggers supplementary delivery; verify the supplementary content is substantively consistent with the voice.

CounterexamplesUnder-delivery — a fee-based service is activated by voice, the fee terms are read only once during the call, and the user is left with nothing in hand; over-delivery — every single routine query sends a lengthy confirmation text message.

Basis and referencesV2-2 governs the fact of playback; V7-4 governs the reviewable path for necessary disclosures.

V7-5Voice is not the only pathMUST¶

In one sentence: For anything that can be accomplished by voice, a path that accomplishes it without voice must also exist.

Applies toproducts and services aimed at the general public.

Rulea task that can be completed by voice MUST have a completion path that does not depend on speaking and does not depend on hearing; that path may be on another device or another channel, but it MUST be discoverable and its cost MUST NOT be significantly higher than the voice path. Making voice the sole available entry point for a service is prohibited. When the product form genuinely has only voice (a voice-only hardware device), this limitation MUST be declared, along with what other channel a user can use to complete the same kind of transaction. Statutory accessibility requirements are governed by the applicable accessibility standards and regulations, and this rule does not substitute for that determination (see Appendix B).

Boundary conditionsthis rule does not require every single function to be available on every channel; what it requires is that the task can be completed, not interface equivalence.

Design applicationthis rule is the shared floor for V1-4, V6-6, V7-1, and V7-2: the alternative paths each of them provides ultimately converge into this one.

Verification examples

• User side: invite participants who cannot use voice (deaf users, users with a speech impairment, users in a sound-restricted environment) to complete the same task, and compare completability and cost.
• Implementation side: walk through the primary tasks and verify each has a non-voice completion path with a discoverable entry point.

CounterexamplesUnder-delivery — a given service can only be handled through voice customer service, with no entry point on the web or in the app; over-delivery — to guarantee equivalence, a difficult-to-use set of key-press interactions is forced onto a voice-only device, leaving the alternative path a formality in name only.

V7-6Exiting means stoppingMUST¶

In one sentence: After the user ends the conversation, there is no more capture and no more executing of unconfirmed actions.

Applies toany voice-interaction product.

Ruleonce a user ends the conversation or exits voice interaction, the product MUST stop audio capture (always-on listening resolves per the user's setting under V6-2) and MUST stop executing any action that has not yet been confirmed; the user MUST be made aware of an action that has already been submitted and cannot be undone. Continuing to advance a flow the user has not confirmed after the conversation has ended is prohibited, and interpreting the end of the conversation as default consent to a pending matter is also prohibited (continuing V4-3). Exiting MUST have a perceptible receipt, so the user knows the system has genuinely ended rather than still waiting. The user may request that progress be retained for continuing later (V7-3), but retaining progress is not the same as continuing to execute.

Boundary conditionsthis rule does not prohibit continuing to execute an already-confirmed task in the background, provided the user has explicitly authorized it; the work that continues after the user leaves, its scope, its end condition, and a way to query or cancel it must be stated in advance; actual progress and results must be queryable, and exiting must not expand what has been authorized.

Design application"ending" is far more ambiguous in voice than in a graphical interface — a user walking away, going silent, or saying "let's just leave it" may all mean ending. Design ending as an event with an explicit receipt, rather than something inferred from a timeout.

Verification examples

• User side: end the conversation while an unconfirmed action is pending, and verify that action was not executed and the user received a clear receipt.
• Implementation side: verify capture actually stops after exit; verify an unconfirmed action does not enter the execution queue.

CounterexamplesUnder-delivery — the user says "never mind, cancel the order" and hangs up, but the order is submitted as usual in the background; over-delivery — every single ending requires the user to confirm item by item which unfinished matters they are giving up.

V7-7Input and output can be chosen independentlyMUST¶

In one sentence: Input and output can be chosen independently.

Applies toproducts with both voice and text capability, or that can provide these two capabilities with the help of assistive technology.

Rulethe product MUST allow input and output methods to be chosen independently, so that "speaking to input, receiving in text" and "typing to input, receiving by voice" are both available among the actually supported combinations; turning off announcements MUST NOT be equated with turning off input, and turning on captions MUST NOT be equated with reopening the microphone. When synchronized text is promised, interim transcription, final transcription, and the task-confirmation result MUST be distinguished, and any revision or playback interruption MUST be reflected in the corresponding presentation. Text and voice may differ in level of detail, but key objects, amounts, negations, conditions, and execution results MUST be consistent. After sound is turned off, necessary state, control receipts, and errors MUST NOT be given through sound alone.

Boundary conditionsthis rule only addresses channel selection and the consistency between voice and its corresponding text; it does not govern multimodal fusion such as gesture or gaze. A screen-free product may satisfy this through an accessible coordinating channel; a combination that is not actually available MUST NOT be promised.

Design applicationvoice input can be retained while announcement is turned off; the user can read results via captions. When a screen reader is in use, redundant product announcements can be turned off to avoid two audio streams competing for hearing at once.

Verification examples

• User side: complete a task using each of two mixed combinations, and while an announcement is playing, turn off sound or revise a transcript, checking whether key values and receipts remain accessible.
• Implementation side: inject a caption arriving first, audio delay, and a mid-stream interruption, and check that unplayed content is not marked as played; confirm the text channel does not lose error feedback.

CounterexamplesUnder-delivery — the "mute" button also turns off the microphone as a side effect, while still displaying that speaking is possible; over-delivery — to keep things synchronized, the user is forced to turn on captions, microphone, and announcement all at once.

Basis and referencesW3C NAUR, REQ 3–9 supports input/output combinations and synchronized text; the state distinctions in this rule are a design derivation made to prevent streaming output from misleading the user.

4. Terminology and definitions¶

Appendix A: Fault-injection verification checklist¶

Executable fault-injection items are given by principle. Each item verifies whether a rule still holds under failure conditions — passing does not mean every requirement is met, and failing means a clear gap exists.

V1 Recognition

1. Issue a command that would trigger an irreversible action against background noise, and verify the system moves to confirmation rather than executing directly.
2. Give a sequence of unrecognizable inputs, and record the turns needed to reach a usable way out, and whether information provided earlier is retained.
3. Have a participant with a noticeable accent, dysarthria, or non-native speech complete the same task, and compare completion rate and the cost of the alternative path.
4. Say an uncommon name and a string of numbers, and check whether the system's final record matches verbatim, with no homophone substitution.
5. Play media audio containing the wake word and a command, and verify the device is not triggered into executing it.
6. Feed the system's own announcement back into the microphone, and verify no self-triggering occurs.

V2 Turns

1. Interrupt during a long announcement, and repeat the stop-latency measurement under weak network and high load to verify it stays within the commitment.
2. Interrupt during a "submitting" announcement, and verify the user can learn whether the submission has already happened.
3. Say a long command with a mid-sentence thinking pause, and verify it is not cut off; after any cut-off, verify continuing to speak works and the first half is retained.
4. Induce a long backend delay, and verify the in-processing signal is triggered, no untrue filler phrase appears, and cancellation is available.
5. Complete a conversation blindfolded or in a driving simulation, repeatedly asking "whose turn is it now," and tally accuracy.
6. During one user's conversation, have another person interject an unrelated remark, and verify it does not enter the task.

V3 Output

1. Walk through the output paths of each scenario, and verify no branch bypasses the single-turn length limit; the "user explicitly requests continuous reading" case stated explicitly in V3-1 does not count as bypassing — for that path, verify pause and locating are available instead. (V3-1)
2. After announcing options up to the cap, ask the user to choose, and tally the rate of needing a repeat and the rate of wrong selections.
3. Run a format scan on voice output: in default mode, verify it contains no unlistenable content such as markup, paths, or table structure; when the user explicitly requests a precise read-out (V3-4), verify the faithful output is genuinely obtainable and not simplified. Record both sides separately — missing either side does not count as passing. (V3-4)
4. Announce a string of numbers and ask the user to repeat it back; at the next step, request a verbatim repeat and verify it is still available and the value is consistent.
5. Give a question the system can only infer an answer to, and check whether the user can correctly judge, after listening, that this is an inference rather than a verified result.

V4 Memory

1. After an interruption, verify four things separately: the already-played segment can be re-listened to and matches verbatim; the unplayed segment is obtainable and was not counted as delivered; the privacy level is re-adjudicated at re-listening (V6-4); and after the cache is deleted, the system truthfully states it is unavailable rather than silently skipping it. Test "repeat" and "continue" separately — do not conflate them into one item. (V2-2, V4-1, V6-4)
2. At the end of a flow, request a change to a mid-flow item, and verify the entire set of questions need not be answered again.
3. Have a user who needs a longer response time complete the same task, and tally the proportion that fails due to timeout; walk through the timeout branches and verify no "timeout equals consent" path exists.
4. Ask a compound question containing three items, have the user answer only one, and verify the unanswered items are not filled with a default value.
5. Transfer to a human or to a screen partway through a flow, and verify information provided earlier need not be said again.

V5 Voice

1. Have participants who were not told in advance interact for one turn and then identify who the other party was, and tally the misidentification rate; walk through every initiation entry point and verify disclosure occurs in each case.
2. Ask "are you a real person," and verify a truthful answer.
3. Run synthesis-marker detection on output audio; test the retention rate after common recording and transcoding chains.
4. Sample voices currently in use: for a voice identifiable as a real person (V5-3), verify it resolves to an authorizing party, scope, and duration, and execute a withdrawal to verify new generation is blocked; for a fully synthetic voice, verify the source category declared in persona.source is true, without requiring a real-person authorizing party to be provided. (V5-3)
5. Check the factual basis, the final audio's perceptible qualifiers, and emotional pressure separately per V5-4; evaluate disputed samples with a user-comprehension test, not by whether the prosody differs.
6. Construct a request beyond capability, and verify the response does not use persona-fitting language to mask the fact that it cannot be completed.
7. Complete a conversation that includes a human-AI handoff, and check whether the user can identify the point of handoff and who was on each side.

V6 Presence

1. Ask a user to mark the intervals they believe the device was capturing, and compare against the actual capture intervals.
2. After turning off always-on listening, verify there is no audio capture or upload, not merely a stop in responding.
3. After capturing in a multi-person environment, verify per V6-3 across three basic cases: with no valid basis of consent, third-party speech is refused entry into the personalization and training pipeline; with a corresponding basis of consent, it is handled per the declared scope and that scope is resolvable; and with speakers indistinguishable, the whole is handled in the more conservative direction. Do not use "must never enter training" as the sole criterion. (V6-3)
4. Send a message containing a verification code to a shared device, and verify the default announcement is the conservative tier; switch the headphone connection state, and verify re-resolution occurs.
5. Trigger a false wake, and verify the record is visible and deletable, with deletion taking effect across all copies.
6. Attempt a high-consequence operation after simulating a voice change, and verify no path is granted on voiceprint match alone and the alternative path is available. Additionally check per the applicable-system branch the product declares: for a product declaring adoption of the NIST SP 800-63 scheme, verify voice comparison is not used as an authentication factor under that scheme — including a "voiceprint plus another factor" combination; for a product not declaring that scheme, check against its actually declared applicable requirement and record the basis. (V6-6)

V7 A way out

1. Request switching to another input method partway through a flow, and verify it does not require starting over.
2. Request a transfer to a human under a recognition-failure state, and verify the entry point still exists and information already collected is carried.
3. Hang up partway through a flow and reconnect, and verify progress is retained with no duplicate charge or duplicate submission.
4. Interrupt a fee disclosure, and verify supplementary delivery is triggered and its content is substantively consistent with the voice.
5. Walk through the primary tasks, and verify each has a discoverable non-voice completion path.
6. End the conversation while an unconfirmed action is pending, and verify that action was not executed, capture has stopped, and the receipt is clear.

Supplementary scenarios:

1. Revise the payee or date in an interim transcript, and verify the old confirmation becomes invalid; an unknown confidence must not be substituted with the model's own self-rated score.

2. Have the user say "stop" while "submitting the order" is underway, and verify the unsubmitted action is paused first and the scope of the stop is clarified afterward; the playback buffer is cleared accordingly.

3. Input a long sentence with a thinking pause and a short response consisting only of "um," and check endpoint timing, backchannel classification, and false-interruption recovery separately.

4. Have a tone arrive immediately but the substantive answer be delayed, and verify the two latencies are recorded separately; check tail behavior by language, device, and network.

5. Test Chinese-English code-switching, homophone names, leading-zero identifiers, and cross-timezone dates; request a verbatim read of a link and a slower speech rate.

6. Unplug the headphones while private information is being announced, and verify the system pauses and clears the cache first before adjudicating speaker content; re-listening also re-adjudicates.

7. Complete a task using voice input/text reception and text input/voice reception respectively, and maintain an available communication method after a transfer to a human.

8. Request a stop or a re-listen after revoking microphone permission, and verify the non-voice control is available and capture is not silently resumed.

9. When the microphone permission is declined, occupied by another application, or unplugged mid-session, verify "listening" does not hold and the user is not required to repeat themselves over and over; restoring permission also does not automatically submit a partial input. (V1-3, V2-5)

10. Confirm a full sentence such as "yes, no wait, move it to Friday," and verify only the complete correction is processed; an old confirmation, a late-arriving transcript after exit, and an old audio callback must not advance a new task. (V1-1, V1-2, V2-2, V7-6)

11. Reconnect after a dropped connection when submission succeeded but the receipt was lost, and verify the original action's result is queried first, without blindly retrying when the result is unknown; re-listening to the announcement does not re-book. (V7-3)

12. After turning off voice-attribute inference, verify the basic task is still usable and a cached profile no longer affects decisions; delete the recording and the derived data separately, and confirm the effect matches the declaration. (V6-7)

13. Interrupt after a long wait, and check the retention starting point; a wait transitioning to a pause does not renew the period, and once actual execution resumes, a subsequent suspension is counted from the new starting point. After the user explicitly deletes progress, do not falsely claim it can still be continued. (V7-3)

14. A safety time limit expiring only triggers a justified fallback action and is not recorded as user consent; a necessary disclosure being interrupted does not count as delivered, nor does it block exiting. (V2-1, V4-3)

15. After switching to a slower speech rate, check that the output duration is re-segmented, and request "say it more simply"; the key conditions remain present, and the audio, captions, and actual execution value are consistent. (V3-1, V3-2, V3-7, V7-7)

Checklist usage convention: each check item is tied to its rule ID and that rule's applicability conditions and boundaries; a legal exception the rule states explicitly MUST enter the checklist as a positive use case, and MUST NOT be judged a failure by a check item. Simulated conditions such as blindfolding or muting can be used to verify a no-vision path, but do not substitute for actual participation by target users with visual, cognitive, or speech impairments.

Classification test (tests the consistency of the principle division): randomly sample 10 specific requirements from the product, and have three or more reviewers who did not participate in writing these guidelines independently judge which principle each belongs to. The denominator of the disagreement ratio is the number of items sampled (10); a requirement counts as one disagreement item as soon as reviewers disagree on its assignment; when disagreement items exceed three tenths (that is, 4 or more), the test fails — at that point the division of principles or the granularity of rules should be adjusted, rather than adding an intermediate layer or a mapping note. This three-tenths figure is a trial maintenance trigger, to be reviewed against actual usage, not a passing-rate commitment. The three known high-risk boundaries in these guidelines (V1/V6, V3/V4, V2/V7, see Chapter 1) should be covered in the sample.

Full-task walkthrough (tests completeness of coverage — the classification test does not carry this responsibility): select two to three real tasks that run through V1–V7 (for example, a voice transaction that includes a fee disclosure, or a private-message announcement in a multi-person environment), and record step by step which rule each step relies on; when a requirement with no place to belong appears, record that requirement and treat it as a rule gap, rather than stuffing it into whichever existing rule is nearby. A high attribution-consistency rate does not mean coverage is complete; the two tests record their conclusions separately.

Appendix B: Basis boundaries and source types¶

The clauses of these guidelines rest on four categories of basis, each recording its binding force and evidentiary use separately, not simply ranked by publishing body; the full entry list is in reference.md:

The parts these guidelines have not yet converged on are stated explicitly here, rather than being papered over with clause-like language:

• No universal performance threshold is set. First-audio latency (V2-6), endpoint silence threshold and maximum wait (V2-3), single-turn length limit (V3-1), parallel-item cap (V3-3), progress retention period (V7-3) — these guidelines only require that each be "clearly defined, justified, and verifiable." These values vary enormously by language, task type, user population, and deployment environment, and the currently cited sources do not support a universal performance threshold. Engineering parameters are recorded in reference.md §4, and are a mechanism reference, not a recommended value, and even less a compliance basis.
• Prosodic effect depends on context. V5-4 can check whether facts and qualifiers are true and perceptible, but cannot set a universal honesty score for pitch or emotional labels; target-language and user research support is still needed.
• Multimodal fusion is out of scope. These guidelines govern only the voice channel. The fusion semantics between voice and screen, gesture, or gaze, cross-modal time synchronization (lip-sync, haptic delay), and conflict adjudication between modalities are not covered. V3-4, V7-1, and V7-7 only touch the boundary between channels; they do not constitute a fusion specification.
• In-vehicle voice is not handled separately. The visual-manual interference, attention budget, and takeover time limit of a driving scenario are prescribed by domain standards and regulations, which these guidelines defer to; parameter resolution for V2 and V3 in an in-vehicle scenario must follow those standards.
• The three boundaries V1/V6, V3/V4, and V2/V7: see the explicit statement in Chapter 1. If disputes over assignment repeatedly arise in practice, the division of principles should be adjusted.

The companion Token glossary is in Design Token.md; these guidelines do not create new obligations through the Token dictionary, and the dictionary does not substitute for these guidelines either.

Appendix C: Complete task example and acceptance record¶

The following is a design example, not a completed product experiment; the task information within it is used only to illustrate the interaction and cannot serve as performance or capability evidence.

C.1 Booking an appointment: from query to a reviewable result¶

Scenario: a user books an institutional service on a phone with a screen, can use voice or text, the fee must be retained for confirmation, and human text service is supported. The task's completion condition is: the date, location, and fee are correctly understood and confirmed, the institution returns a unique booking result, and the user can look up the record; a single "okay" does not indicate the booking is complete.

Contrast branches: a low-consequence time query adds no confirmation; the user saying the date and location together in one go is not split into separate re-questions; changing a value before final confirmation only re-checks the affected content; the booking is not submitted when no accessible fee-record path exists. This checks for both omission and over-confirmation at once.

C.2 One executable acceptance record¶

C.3 Metrics and passing conditions¶

The following are measurement definitions. Numeric thresholds are set by the project before testing; different metrics are not weighted-averaged into a single "voice quality score."

Report sample size and uncertainty grouped by language/accent, speech/hearing or cognitive needs, device and listening method, noise, and network; a small sample should be flagged as insufficient, and a group's compliance must not be inferred from a high overall score. No error observed in a performance sample does not prove an error can never occur.

Acceptance runs on three tracks: a static check of content and rules; a systems experiment on capture, routing, stopping speech, submission, and recovery; and a comprehensibility and completion-cost study with target users. A hard-floor failure MUST NOT be offset by speed, satisfaction, or an overall score. When evidence is insufficient, explicitly limit the scope of support or keep the conclusion pending verification; after a model, voice, processing use, or environment changes, only carry forward evidence that still covers the actual conditions.

---

Implementation acceptance scenarios¶

The scenarios below turn the existing clauses into reviewable acceptance inputs, without setting an additional universal performance threshold. Select according to the product's applicable capability, supplementing real devices, users, input sequences, and evidence; record the reason when not applicable, and an unexecuted item MUST NOT be recorded as passed.

Each scenario separately checks the configuration's effective values, the execution record, and a result the user can understand. Retain version, target, event timestamps, failure scope, and recovery result; an unknown external result is not filled in as success or failure.