Can I ask the system follow-up questions?
Relevant when users need to probe a decision beyond what the static explanation shows: particularly useful in expert-facing tools where caseworkers, clinicians, or analysts need to investigate edge cases.
Static explanations answer the question the designer anticipated. Inspection Dialogue answers the question the user actually has.
A user reviewing a declined loan may understand the top factors but want to ask: "Would it have changed the result if I'd submitted the income statement from my second job?" A clinician reviewing a diagnosis may want to ask: "Why did you weight this symptom so heavily given the patient's age?" A caseworker may want to ask: "What would this score be if I corrected the employment dates?"
These are follow-up questions, and static attribution panels, bar charts, and factor lists cannot answer them. They require interactive inspection: a mechanism for the user to probe the explanation, test assumptions, and get specific answers to their specific questions.
As AI interfaces increasingly incorporate conversational elements (chat interfaces, copilots, AI assistants), the inspection dialogue pattern becomes both more natural and more important. It bridges the structured display patterns of traditional XAI with the conversational interaction model of LLM-powered systems.
Provide an interactive mechanism through which users can ask follow-up questions about a decision or output, probe specific factors, test hypothetical changes, and receive direct answers: without requiring technical knowledge.
A set of pre-defined, contextually relevant follow-up questions presented as quick-select options. Research on how users question context-aware systems identifies four recurring question types that inspection dialogue must support: - Why: "Why did employment history matter so much?" (explaining the factors) - Why not: "Why wasn't my income enough on its own?" (contrastive, ruling out alternatives) - What if: "Would a higher income have changed the result?" (hypothetical / counterfactual) - How to: "What would I need to do to get a different outcome?" (recourse-seeking) Generating contextually relevant questions from each of these types, based on the actual factors in the decision, provides structured coverage of what users genuinely need to understand.
An open text field allowing users to ask their own questions. Most powerful but requires the system to understand and answer reliably. Should be paired with grounding indicators to signal when the system is uncertain about its answer.
A structured form allowing users to change one variable and see the hypothetical impact: "What if my income were €X?" This is inspection dialogue structured as a counterfactual query: a bridge between inspection and Counterfactual Explanation.
A side panel with a conversational interface specifically scoped to the current decision. The system can only answer questions about this decision, not general questions about the AI. Scoping prevents the conversation from drifting outside what the system can reliably answer.
When a user asks a question, the answer appears as a new card anchored to the relevant part of the explanation, not as a free-floating response. This keeps the inspection grounded in the specific decision rather than abstractly conversational.
A record of the questions asked during an inspection session: useful for audit purposes and for caseworkers who need to document the reasoning behind an override decision.
An inspection interface that can answer any question is also an interface that can produce unreliable answers. Scope the system to the decision at hand. "I can answer questions about this specific recommendation" is safer and more trustworthy than a general-purpose AI chat window.
Most users don't know what questions to ask of an AI system. Pre-defined question options that are contextually generated (based on the factors that appeared in the attribution) remove this burden and guide users toward questions the system can actually answer well.
Inspection dialogue answers should surface their reasoning, for example "this is based on the employment factor, which contributed −0.34 to the score", not standalone assertions. Answers without visible basis cannot be evaluated or trusted.
If a user asks a question the system cannot reliably answer, say so explicitly rather than generating a plausible-sounding but unreliable answer. This is especially critical in domains with legal or safety implications.
Questions asked during inspection are part of the decision record. A caseworker who asks "what if I adjust the employment dates?" and then overrides based on the answer has made a decision that should be auditable.
Interactivity vs. reliability
The more flexible the inspection dialogue, the more risk that the system will produce unreliable answers. Constrain what can be asked to what can be answered reliably.
Depth vs. efficiency
Inspection dialogue is for users who need depth. In high-volume workflows, it may slow down experienced users who don't need it. Make it accessible but not mandatory: a panel that can be opened, not an inline interruption.
Transparency vs. gaming
"What if I change this variable?" is the first step toward gaming the system. In some contexts (loan applications, risk scoring) detailed counterfactual inspection may need to be limited or scoped to authorized users only.
Layering offers depth through structure. Inspection dialogue offers depth through interaction. For most users, layering is sufficient; inspection dialogue is for users who need to go further.
"What if" inspection is functionally a counterfactual query. The patterns share ground and can be combined: counterfactuals are a structured form of inspection dialogue.
Attribution provides the content that inspection dialogue allows users to probe. The two patterns work together: attribution answers the first question, inspection dialogue answers the follow-up.
For caseworkers, inspection dialogue is part of the override workflow. The investigation a caseworker conducts before an override should be logged as part of the decision record.
In LLM-powered inspection interfaces, grounding indicators are essential. Users need to know when the system's answer to a follow-up question is well-supported vs. potentially fabricated.
Lim & Dey (2009) — Why-Oriented Explanations in Intelligent Systems
studies how users ask "why" questions of context-aware systems and what kinds of answers satisfy them. Foundational for understanding the natural follow-up question structure that inspection dialogue must support
establishes that explanation is inherently interactive and conversational, not a static transfer of information. Directly motivates inspection dialogue as a pattern
Ehsan et al. (2021) — Human-Centered Explainable AI
proposes that explanations must be co-constructed through dialogue between user and system, not delivered as pre-packaged outputs