False-wake audio should be discarded by default

What it is

After hours in an open office, a meeting-room speaker wakes on a near-neighbour word from a TV ad and takes two people still working into the buffer. Nobody issued a command. If that stretch is written as a history item, a detector error becomes a playable file. Default discard of false-wake audio: the default is to drop the buffer, not to file it and wait for someone to delete. The people involved were often absent or missed the lamp. The chance to delete never occurred.

Why it happens

A keyword hit opens the same buffer and uplink as a true wake. A true wake has a later, recognizable user intent: a command, or an explicit cancel. A false wake lacks that intent, yet it readily inherits a write policy of “save for improvement / save so the user can review.” The write reifies a state-machine error as an object, and the object enters history, maybe leaves the device. Default discard treats “no user intent” as a negative condition on retention: a wake count may be kept; a playable file is not created. Inspect-and-delete cannot save this path, because delete presupposes knowing the item exists. People in a false wake often find out much later, or never. Default retain demands an auditor who is not there. Discard happens before the write, not after someone later finds the item.

Studying it

A write audit on the false-wake path: overnight or for several hours in a desk with TV speech, mark every wake with no following user command, and see whether the buffer becomes a playable history item and whether it leaves the device. Compare firmware that discards by default with firmware that writes history by default. The dependent measure is audio objects from unintended sessions, not the false-wake count itself — count is an input event; object count is a retention event. The next day, ask who was present whether they know a recording was left overnight. Not knowing, plus an object, means default-write already turned the error into a file. “Users can delete it in activity history” is not a pass on this condition.

Where it stops holding

Someone says the wake word and changes their mind: that is cancel after an intentional open, and the buffer policy may differ; it should not be folded into default discard of false wakes. On-device spotting that never writes a file has already discarded; a wake count is still useful, or whether a false wake happened cannot be known. Forensic or regulatory scenes that must keep every wake will override default discard; that has to be written at deployment time, not faked as the consumer default. Treating a false wake only as an annoying sound misses the layer where the buffer became a file. Conversely, discarding audio does not mean the false wake did not interrupt whatever was going on.

Applying it

• Wakes with no following user command, or wakes explicitly marked as false accepts: the buffer is not written to history and is not uploaded. A non-playable trigger count is allowed.
• Do not hang a default “help us improve” check on false-wake clips. An improvement program should take intentional sessions only, under a separate consent.
• If the product still offers a “let me hear false wakes” debug switch, it must default off and live in expert settings.
• How to check: leave a TV on overnight in a meeting room or at a desk. The next day the account must contain no playable items without a user command. If it does, the product is still handling an error that should never have become a record as “save then delete.” Discard before the write.

Related

• Same group: M4.05.1 Retention scope has to be stated in terms people can check · M4.05.2 People must be able to inspect and delete stored recordings
• Nearby: C7.08 False wakes · M4.10 Retention and deletion of voice data · M4.07 Felt privacy of always-on microphones
• Search terms: default discard of false-wake audio · false accept buffer · retention