Explicit confirmation is reliable but slow

What it is

Explicit confirmation makes “did I get that right” its own turn: the system restates what it will do and waits for a separate yes or no. A registrar system, before dropping a course, says “I will drop Wednesday’s econometrics — is that right?” A wrong course code can still be caught; every correct drop also pays for an extra turn. Reliability comes from splitting execution from consent. Slowness comes from that split.

Why it happens

Explicit confirmation inserts a closed subdialogue: question, wait, judge the answer, then act. If the content turn was misheard, the confirm turn has a chance to stop it. If the content turn was right, the confirm turn still charges a full turn’s time, endpointing, and another recognition. What stretches the flow is not “a few more words” but one more floor exchange — speak, silence, listen, speak again.

The cost is structural. When a primary task already holds attention, the extra turn competes with it. People often plan a “yes?” more carelessly than they planned the content turn, so the confirm turn becomes a new failure site. What it buys is taking “continue by default” out of the system’s hands: no consent heard, no execution. Reliability is purchased with throughput. The bill is extra turns per success, not a feeling of being safer.

Studying it

Confirmation-cost studies run the same task two ways: act after the content turn, versus insert an explicit confirm. Dependent measures come in pairs: false execution (should not have happened), false refusal (should have happened and was blocked), turns and time from wake to done, mid-task abandonment. Independent variables can include how hard the content turn is to recognise (proper names, neighbouring course codes) and whether the confirm turn accepts “no, the other one.”

Do not report only “errors fell after adding confirmation.” Put extra turns as cost and errors avoided as benefit on the same table. Student participants dropping the same course repeatedly will understate impatience on the confirm turn and understate casually tossed “yes.” Live logs can count the difference in mean turns on a skill before and after explicit confirmation is switched on.

Where it stops holding

When the content turn is already tiny and almost never wrong (a closed command like “lights on”), marginal reliability of an explicit confirm is near zero and the slowness is pure loss. When people need to speak less in public, one more confirm is one more exposure. A confirm sentence that re-reads the entire content inflates the slowness; asking “right?” with no content leaves people unsure what they are affirming. Screenless actions that cannot be changed in the next breath will force explicit confirmation; the slowness is then the channel charging, not a design miss.

Applying it

• Default to explicit confirmation only on skills where a wrong execution cannot be undone with the next spoken line. Skills that can be corrected in place do not get this turn.
• The confirm sentence states in one line what will happen, then waits. Do not explain policy on the confirm turn.
• Book failures of the confirm turn separately: silence, off-prompt replies, “yes” heard as “no.” Recognition budget on the confirm turn must not be cheaper than on the content turn.
• How to check: on the same skill, compare completion time and false executions with explicit confirmation on versus off. If time rises and false executions barely move, the turn is only dragging. If false executions drop clearly, the slowness is payable.

Related

• Same group: M2.03.2 Implicit confirmation embeds the ack in the next move · M2.03.3 Confirmation strength must match consequence
• Nearby: M2.08 Explicit and implicit confirmation · M1.03 Dialogue turns · M2.09 Matching confirmation to consequence
• Search terms: explicit confirmation cost · confirmation turn · dialogue efficiency