After timeout, default to not executing

What it is

“Send Zhang a hundred?” The room goes quiet. When the timer fires, the money should not move. “Next track?” — silence is not a nod. A non-execution default on timeout treats no-speech as no uptake and leaves the world unchanged: no send, no purchase, no delete, no call. Completion rates will fall. The cost of a “no” stolen by silence is taken back from the user. This is not the same decision as “after how many asks we close the session.” Closing may still happen. Closing must not fire the pending intent.

Why it happens

A timeout is a missing observation, not a speech act. Mapping it to yes (or to “continue with the best guess”) treats non-behavior as consent. In conversation, silence after a request for confirmation is typically non-uptake. It does not license the proposed action. The safe default is the world as it was before the question.

Execution is tempting because it lifts completion and saves a re-ask. The bill lands on someone whose “no” was not heard, or on someone who walked away and was counted as “ok.” High-consequence moves that confirmation was meant to block then pass the gate at the moment with the least spoken evidence. Using silence as yes on low-consequence moves also trains an expectation that later, real confirmations can be replaced by shutting up.

Studying it

Inject silence at confirmation points. Map timeout onto three policies: treat as yes, treat as no / do not execute, re-ask then stop. Pair scenarios by consequence: a transfer confirmation against “play the next track.” Dependent measures: unauthorized executions, recovery cost (undo, a phone call to claw back), and after-the-fact judgments of “did it have my consent.” Do not optimize task completion — that metric is born biased toward timeout-as-yes.

Legal and ethics review can run in parallel: if copy writes silence as consent, the default is already broken in the document. The lab must give people a real “no” to say, and sometimes cover it with noise, or the harm of execute-on-timeout will not show.

Where it stops holding

Some defaults follow physical safety, not dialogue consent: a vehicle asking “keep braking?” may need to keep braking on timeout. That is a world-safety state, listed on its own whitelist, not generalized into “timeout may act.” An alarm whose silence means snooze is a protocol the product defined; it belongs in settings, not as a stealth confirmation. A short “mm” as yes is spoken uptake, not a timeout.

Applying it

• On the timeout path, do not fire the pending intent. Speak a non-execution (“I won’t transfer yet”), then close or wait for the next wake.
• In docs, speech, and tests, never write silence as yes. A valid confirm is recognizable affirmative speech (or an equivalent key), not a clock.
• Whitelist only actions that hold a safer world state (stay locked, keep braking). Each line must say why executing is lower-regret than not. Transfers, orders, and sharing do not belong there.
• In the test suite, insert full silence at every confirmation. Except the whitelist, execution count must be zero. Any smoke means timeout was treated as consent.

Related

• Same group: M1.11.1 Timeout thresholds should be set by task type · M1.11.2 Re-prompt intervals should lengthen each time
• Nearby: M1.07 Silence and Timeouts · M2.03 Confirmation Strategies · M2.09 Matching Confirmation to Consequence
• Search terms: non-execution default on timeout · timeout is not consent · silence as non-uptake