Retention scope has to be stated in terms people can check

What it is

A hotel-room assistant can kill the lights and set tomorrow’s wake-up. Guests do not know whether those requests became playable recordings, whether they live at the hotel group or only on this speaker, whether a breakfast order counts as a “session.” Disclosed retention scope is a checklist people can audit — which events create an audio object, whether the object leaves the device, what it is for — not a sentence that says “we protect your privacy.” If the scope cannot be stated, inspect and delete have no object.

Why it happens

A dialogue system decides at several cuts whether a stretch of audio becomes a record: the unwoken buffer overwritten, the request after a wake, the user saying “remember this,” clips enrolled in an improvement program. Each cut yields a different set. Guests, roommates, meeting organizers need the border of the set, not the vendor’s attitude. If the scope lives in the middle of a long privacy policy, or folds “assistant,” “improvement,” and “cloud” into one clause, the border cannot be interrogated. Disclosure turns the cuts into answerable yes/no items. A nutrition-label layout splits “leaves the device / written to history / used for improvement” onto separate rows because people can check those bits one at a time, not a paragraph. When scope is unclear, default behavior finishes every choice, and people believe they left no recording.

Studying it

A privacy nutrition-label comprehension test: after the in-room card or the settings page, three yes/no items — does unwoken speech leave a playable file, does a successful “lights off” write history, is the improvement program a separate consent. Score whether the cuts were separated. Contrast with a group that only gets the current long policy, same three items. Hotel check-in is the right field — people have tens of seconds at the desk. Walk the device: for event classes the copy says are not saved, do audio objects still appear locally or on the account. When copy and objects disagree, the quiz key follows the objects.

Where it stops holding

On-device keyword spotting that never writes a file can have no “history recording” row, and still has to put “no object is created” in the scope; the empty set is a scope. Enterprise meeting rooms that retain under company policy shift the audience of the disclosure to people entering the room, not a consumer toggle. Legal “processing” may be wider than “kept recordings”; a label that only covers audio files can still omit a one-shot inference.

Applying it

• On the in-room card and the settings home, a table of event × destination: waiting for wake, successful request, user-asked remember, improvement program — each row whether a playable object is created, whether it leaves the device.
• One “cloud experience” master switch must not turn on both history writes and improvement upload; the two rows must be able to close independently.
• Treat three yes/no items as the acceptance test for unboxing or check-in copy, not brand adjectives.
• How to check: a guest who has not read internal docs finishes the card with all three items right. Then a real overnight, and the account must not contain objects the card said would not exist. If they do, change the scope copy or the write path until they match.

Related

• Same group: M4.05.2 People must be able to inspect and delete stored recordings · M4.05.3 False-wake audio should be discarded by default
• Nearby: M4.10 Retention and deletion of voice data · M4.02 Always-on microphones · C7.08 False wakes
• Search terms: disclosed retention scope · privacy nutrition label · retention