ADR-0017: Voice OFF by Default Safety Policy

Status: Accepted
Date: 2026-05-27 (retroactive - voice shipped in v2.0.0)
Decision-makers: Waldemar Szemat

Context and Problem Statement

ADR-0013 added voice (TTS via ElevenLabs eleven_multilingual_v2, realtime WebSocket STT) as an extension to the demo SPA. That ADR captures the design but does not codify the safety stance for the default state of voice or the consent gate that governs it.

Voice in a regulated-adjacent demo introduces a different consent and risk surface than text:

Impersonation / deepfake: a synthesised voice can be misinterpreted as a recording of a real person.
Privacy: STT audio is processed in-flight even when the demo does not retain it; the consent burden is higher than for text.
Audio-cue authority: a voice that sounds clinical can be heard as instruction even when the text frames a refusal.

The decision is: what is the default state of voice, and how is consent to it recorded, for a first-time visitor?

Decision Drivers

Consent-first posture: regulated-adjacent demos demonstrate consent, they do not assume it.
Deepfake exposure: defaulting voice ON puts a synthetic voice in every visitor’s ears as the first impression. That is the wrong signal.
Locale parity: the default must be uniform across en / es-419 / pt-BR. A locale that defaults differently would be hard to defend.
Reversibility: opt-in must be revocable any time without losing the text experience.

Considered Options

Option A: Voice ON by default; the toggle is a “mute” affordance.
Option B: Voice OFF by default; opt-in captured as explicit, server-recorded consent per key, persisted across sessions.
Option C: Voice OFF by default; opt-in recorded client-side in localStorage per device.
Option D: Voice gated behind an explicit privacy modal at every session (no persistence).

Decision Outcome

Chosen option: Option B - Voice OFF by default, unlocked only by explicit consent that the server records per key and persists across sessions. The load-bearing reason is consent-first posture: a regulated-adjacent demo that talks the moment a visitor opens it has chosen the wrong default. Recording consent server-side, per key, respects the user’s earlier decision without nagging at every session and keeps the gate enforceable where a client-side flag could not be; the explicit footer notice “Audio NOT retained” is shown regardless of voice state, so the consent context never disappears. Voice itself is a paid entitlement (ADR-0013), so the consent gate only ever applies to keys that can use voice at all.

Confirmation

Voice is off by default in the demo SPA; no audio turn is served until consent is recorded.
Consent is recorded server-side per key. Until it is granted, a voice request is rejected with 403 consent_required; the server, not the browser, holds the consent state and persists it across sessions.
Voice affordances appear only for keys that carry the voice entitlement; an unentitled key is never offered voice regardless of consent.
A one-time voice disclosure is the consent gate the user passes to enable audio.
The deepfake-and-consent governance note documents the policy and references this ADR (see voice consent and deepfake policy).
Locale parity: voice is OFF by default in en, es-419, pt-BR; the disclosure is fully translated in all three.

Consequences

Positive

First-visit experience is silent. The consent decision is the user’s, not the demo’s.
Deepfake exposure is bounded to users who explicitly enabled voice.
The “Audio NOT retained” footer notice carries the consent context visibly at all times.
Locale parity is enforced.

Negative

One extra click for users who actively want voice. Small UX cost.

Neutral

Consent is recorded per key on the server, so a user’s decision follows the key across devices and sessions rather than living in one browser’s storage.

Pros and Cons of the Options

Option A: Voice ON by default

Good, because zero-friction discovery of the voice feature.
Bad, because a synthetic voice plays on first visit - consent is retroactive, not prior.
Bad, because deepfake exposure for every visitor.
Bad, because hard to defend to a clinical reviewer.

Good, because consent-first.
Good, because deepfake exposure is bounded to opted-in users.
Good, because consent is enforced on the server, where a client-side flag could be bypassed, and persists across sessions and devices.
Good, because the disclosure carries the explicit voice + privacy framing.
Bad, because one extra click for users who want voice, plus the server-side consent record a client-only toggle would not need.

Option C: Voice OFF by default + client-side `localStorage` opt-in

Good, because it is simple and needs no server-side consent record.
Bad, because the consent state lives in one browser and does not follow the user across devices or sessions.
Bad, because a client-held flag cannot be enforced server-side, so it is the wrong tool for gating a paid, consent-sensitive capability.

Good, because consent is re-affirmed each session.
Bad, because nag-pattern UX. Drives consent fatigue.
Bad, because a user who consented yesterday is asked again today for no operational gain.