Home/ Part VIII — Retrieval, Grounding, and "Don't Make Stuff Up" Engineering/26. Guardrails for Grounded Systems/26.2 Confidence & uncertainty UX

26.2 Confidence & uncertainty UX

Overview and links for this section of the guide.

On this page

Goal: make uncertainty usable (not scary)

Users don’t need a “probability” number. They need to know:

  • how confident the system is,
  • why it’s confident (sources),
  • what to do next if it’s not confident.

Good uncertainty UX turns “the model isn’t sure” into a helpful workflow: ask a clarifying question, show sources, or escalate.

Why “confidence” is tricky

Models can sound confident even when wrong. Also, “confidence” can mean different things:

  • Retrieval confidence: did we retrieve relevant evidence?
  • Answer confidence: is the question unambiguous and fully supported?
  • Policy confidence: are sources authoritative and current?

Your UX should reflect evidence quality, not the model’s tone.

Avoid fake precision

Numeric probabilities look scientific but are usually uncalibrated. Prefer discrete levels and evidence-based explanations.

A practical answer state machine

Model your product around explicit states:

  • Answered (high confidence): strong evidence, clear citations.
  • Answered (medium confidence): evidence exists but question has ambiguity or limited coverage.
  • Needs clarification: question is ambiguous; ask a follow-up question before answering.
  • Not found: evidence missing; suggest what to provide or where to look.
  • Conflict detected: sources disagree; surface the conflict and ask for resolution.
  • Refused / restricted: policy or permission prevents answering; provide escalation path.

This prevents the “always answer” trap and makes behavior consistent.

Signals you can use to estimate confidence

Use pipeline signals instead of the model’s self-assessment:

  • Retrieval score margin: are top results clearly better than the rest?
  • Evidence coverage: do retrieved chunks directly answer, or just mention related terms?
  • Citation density: does every claim have strong citations?
  • Source authority: are citations from canonical docs or informal notes?
  • Conflict presence: do sources disagree?
  • Not-found detection: did the model correctly abstain when evidence is missing?

UX patterns that build trust

High trust patterns for grounded systems:

  • Show sources by default: citations with expandable quotes.
  • Explain limitations: “I couldn’t find X in the documents provided.”
  • Ask one good question: clarify ambiguity with a single targeted follow-up.
  • Offer a next action: “Search these sections,” “contact owner,” “file a ticket.”
  • Never hide conflicts: show conflicting quotes and explain why it’s unclear.

Language guidelines (what to say)

Prefer language that is:

  • evidence-first: “According to [source], …”
  • honest: “Not found in the provided docs.”
  • actionable: “To answer, I need the policy section that covers …”

Avoid language that implies certainty without evidence:

  • “Definitely,” “always,” “guaranteed,” “it must be,” when not explicitly supported.

Schema fields for confidence and uncertainty

Add fields that represent your state machine:

{
  "status": "answered" | "needs_clarification" | "not_found" | "conflict" | "refused",
  "confidence": "high" | "medium" | "low" | null,
  "follow_up_question": string|null,
  "missing_info": string[],
  "conflicts": [...]
}

Drive the UI from status, not from “confidence tone.”

Where to go next