People must be able to inspect and delete stored recordings

What it is

A shared-apartment speaker has taken a week of kitchen requests: whose delivery, whose alarm, whose muttered calendar. Opening the account, an owner should see those stored recordings and delete any one of them. Inspect and delete voice history: inspect is how you know what is in the set; delete is what keeps retention from being one-way. A button that lives only in a vendor console, or a control that stops future saves without touching items already there, is not this capability. Dialogue history is a trace of life in the room, not a log only engineers can open.

Why it happens

After a successful wake is written, the audio object has an identity: time, device, sometimes a playable waveform. If that identity exists only on the server, the owner cannot check whose voice the kitchen kept this week. Inspect means a user-facing list in time order, with playback or at least a readout of which request it was. Delete means the object the user can see is gone. Shared apartments harden the need: one person’s request shows up in a history another person can open; inspect and delete are how people present clean up each other’s traces. Uninspectable retention is a secret file. Inspection without delete is an exhibition. A switch that stops future writes does not reach backward, so “stop saving” does not stand in for “delete what is already there.”

Studying it

Walk three surfaces — account, companion app, the device itself: does the same kitchen request appear, can it be played, does it remain on the other two after a delete. Time how long a non-technical user needs from opening the app to deleting a named day’s records. Ask both roommates whether they know the other can see their requests. Reading whether the policy says “you may delete” yields an overly kind result — look for the button, and for the object after the click. A lab account pre-filled with fake history tests “can they find it” better than an empty account.

Where it stops holding

On-device spotting that never writes a file has no inspectable audio object; a wake count should still exist, or people cannot know what happened this week. Enterprise devices may forbid deletion; that belongs in the deployment write-up, not as a consumer default. When several people share one account, delete rights collide — what is needed is per-item delete, not one “clear the household” that wipes records someone else still wants. Inspecting can expose content again: reading history aloud at an open-plan desk is a second broadcast. Inspect-and-delete governs objects that already exist. It does not answer whether the object should have been written in the first second.

Applying it

• Activity history lists each saved request in time order. In a shared apartment, play and single-item delete should work on the device or in the account, without a hunt through a buried web console.
• After a successful delete, the same item must be gone on the speaker, the phone app, and the web. Removing it from one list is not enough.
• “Stop saving new recordings” and “delete recordings already stored” are two actions. One toggle must not impersonate both.
• How to check: after real kitchen requests in a shared apartment, the other roommate finds and deletes one item within five minutes. If they cannot find it, cannot delete it, or the speaker can still play it, the capability has not been delivered.

Related

• Same group: M4.05.1 Retention scope has to be stated in terms people can check · M4.05.3 False-wake audio should be discarded by default
• Nearby: M4.10 Retention and deletion of voice data · C7.08 False wakes · M4.02 Always-on microphones
• Search terms: inspect and delete voice history · activity history · retention