AI abstention design
Design three outcomes for missing evidence
Give the application explicit answer, clarification and escalation states. Keep access denials separate so uncertainty handling cannot bypass permissions.
In this article
Define the response contract
Use a structured result that identifies the outcome and the evidence supporting it. An answer can contain supported claims, a clarification can contain one necessary question, and an escalation can identify the unresolved issue and permitted handoff.
Do not use a free-form confidence sentence as the only control. The application needs a state it can validate and render consistently. It should also enforce access and approval requirements before accepting an actionable result.
{
"outcome": "clarification",
"question": "Which product version is installed?",
"reason": "The available instructions differ between the two supported versions.",
"evidenceIds": ["manual-v2", "manual-v3"]
}The example is an application contract, not a claim that the model's chosen state is always correct. Validate the evidence identifiers and evaluate the classification against reviewed tasks.
Make clarification resolve something specific
Ask only for a detail that changes the answer. If the available sources differ by product version, the version question is useful. Asking for a general description of the problem again may simply repeat information the user already supplied.
Save the unresolved requirement with the conversation so the next reply can continue the task. Do not restart retrieval and lose the reason for the question after one turn.
Set a limit on repeated clarification. If the system keeps asking variations of the same question, provide a clear handoff or explain which information remains unavailable.
Build escalation from the evidence gap
An escalation record should include the user's task, supported findings and unresolved point. Route it only through a configured, authorised destination. The assistant should not invent a contact or promise a response time the service does not provide.
Where no integrated handoff exists, give the user a concise summary they can take to the appropriate owner. Be explicit about what the application has and has not submitted.
Keep sensitive source material out of the handoff unless the recipient is allowed to read it. The next step is still part of the application's data flow.
Test outcome selection and rendering
Use cases that are fully answerable, answerable after one detail and unsupported by the corpus. Add an unauthorised request to verify it follows the access-denial path rather than a confidence-based retry.
Inspect the user-visible text. A limited answer should not begin with an unsupported conclusion, and a clarification should preserve the original task. Track unnecessary refusals and successful clarification completion so the product remains useful while acknowledging its limits.
Primary sources
Microsoft Learn: retrieval and answer evaluatorsOWASP: authorisation guidanceReferences checked 11 September 2026.