Audio and transcripts are two data objects that need separate handling

What it is

One utterance leaves at least two objects: audio (the waveform — re-identifiable, re-trainable, close to biometric in some jurisdictions) and transcript (searchable text that enters logs, support tickets, analytics warehouses). “Voice history” in a product often points at only one of them. Deleting recordings is not deleting sentences; keeping text is not still holding the sound. The two objects need separate handling. This is not “disclose which recordings you keep,” and not “users must be able to see and delete history” — those are scope and entry. This is that the objects themselves are two.

Why it happens

The voice pipeline forks soon after wake. Waveforms go to object storage for review, model improvement, dispute playback. The decoder’s word lattice becomes text for NLU, search, personalization, support. After that the two lifetimes are independent: compression, cold storage, indexing, permissions, whether they leave the region, can all be configured apart. Text leaks by being searchable (“find yesterday’s address”). Audio leaks by being re-identifiable and re-processable (run another recognizer, build a voiceprint, hear affect). Their legal character differs too: voice used to identify a speaker sits closer to special-category data; the sentence as ordinary personal data can still be retrieved and quoted. If the interface has only the word “recordings,” users who delete the waveform believe the sentence left with it; text in the warehouse and the ticket system is often outside that button’s reach. The other way around — delete text, keep waveform — leaves a seed that can grow a transcript again at any time.

Studying it

Build a data map: after one real session, list the waveform bucket, the transcript table, the search index, the support copy. Ask the user to follow the product copy for “delete recordings,” then look for that sentence in all four places. What remains is the measure, not satisfaction. Cross what the user thinks disappeared with what actually disappeared — mismatch means the two objects were not treated as two.

In interviews ask both: “after delete, is there still your voice,” and “are there still the words you said.” “Are the privacy settings usable” collapses the two objects into one attitude.

Where it stops holding

On-device dictation that discards the waveform after recognition and never writes text has no persistent pair; this card does not govern retention, only a momentary buffer. Legally retained call recordings may forbid deleting the waveform and should still allow separate access control on the transcript. Live captions that exist only in device memory leave no second object when the session closes. Counting all metadata (timestamp, device, wake type) as a “third object” dilutes the problem. Treat audio and text as the two that must be separated; metadata travels with them.

Applying it

• History and delete treat “the sound” and “the words said” as two objects and two actions, and say whether the other remains when one is deleted.
• Acceptance for “delete recordings” is an empty waveform bucket and no re-decodable cache. Acceptance for “delete transcript” is that the sentence is no longer findable in history, search, or ticket quotes. Measure both.
• Do not default to keeping text indefinitely as a side-effect of the waveform. Text is highly searchable; it needs its own lifetime.
• How to check: speak a sentence that contains an address, delete recordings, then search for that address in the companion app, the web console, and support search. If it is found, text is still an unhandled object.

Related

• Same group: M4.10.2 Deletion has to cover derived data · M4.10.3 The default retention period outweighs the settings page
• Nearby: M4.05 Retention of Voice Data · O1.07 Right to Erasure and Data Deletion · C7.08 False Wakes
• Search terms: audio versus transcript · voice data objects · separate deletion