Low-confidence situations should request confirmation rather than execute silently at a threshold

What it is

A low-confidence confirmation request pauses commitment when object, instruction, or plan uncertainty meets meaningful error cost, asking a person to choose, add information, or approve. A bare threshold silently executes borderline passes and rejects low cases without gaining evidence.

Why it happens

Confirmation injects human context and can remove several candidates through one interaction. Triggering depends on error cost, interruption cost, and availability rather than one confidence value. Frequent vague requests create burden and reveal a recurring defect that should be fixed.

Studying it

Silent threshold, fixed request, and cost-sensitive request can be compared on avoided error, request count, latency, interruption, nonresponse, and reliance. Confidence must be calibrated, and human answers can be wrong. Busy, delayed, and refusing users should be represented.

Where it stops holding

Emergency windows may require predefined safe action without confirmation. Low-risk reversible choices can use transparent defaults. One click does not transfer high-stakes responsibility; authority must match the request and nonresponse remains conservative.

Applying it

• Trigger from expected error loss, confirmation cost, and availability, not a score alone.
• Present bounded candidates, decisive differences, and intended action with refusal and deferral.
• Test workload, wrong answers, and nonresponse, measuring confirmations per severe error avoided and interruption-induced error.

Related

• Same group: X3.08.1 Perceptual and decision confidence must be presented in human-interpretable form · X3.08.2 Binary success/failure presentation hides intermediate uncertainty · X3.08.3 Expressing uncertainty should not undermine overall system credibility
• Adjacent: X3.04 Failure and help-seeking · X4.02 Human intervention
• Search terms: selective prediction · clarification request · human confirmation