Explainables
Understand

Counterfactual Explanation

causal reasoninguser agencyinteractive inquiry
User question

What would have changed the outcome?

Consulting signal

Surfaces when clients need to tell affected users not just why a decision was made, but what a realistic path to a different outcome looks like: common in financial services, benefits, and hiring contexts.

Overview

Why this pattern exists

Attribution tells users what mattered in a decision. Counterfactual explanation tells users what could have changed the outcome. These are related but different, and both are needed for a decision to feel genuinely explainable.

A counterfactual says: "If your income had been €500 higher per month, this application would have been approved." Or: "If the employment gap had been under 6 months, the risk score would have fallen below the referral threshold." It answers the question that users naturally ask after receiving an adverse outcome: what would have been different if...?

This is not the same as Actionable Recourse, though the two are closely related. Counterfactuals are explanations: they describe the decision boundary. Recourse is practical guidance: it tells users what they can actually do. A counterfactual might describe a change that is technically possible but practically out of reach for this user. Recourse filters for what is realistically controllable.

Used together, counterfactual explanation provides the understanding and recourse provides the path forward.

Design goal

Show users the minimum or most relevant changes to their situation that would have produced a different outcome: making the decision boundary visible without requiring users to understand the model.

Usage guidance

When to use

  • The decision was adverse and users need to understand what would have changed it
  • The factors involved are partially within the user's control
  • The interface supports a re-application or re-evaluation workflow
  • Users need to understand where the decision boundary lies (professional decision-support contexts)
  • Legal or regulatory requirements specify that users must be told what they can change (GDPR Article 22)

When not to use

  • Showing the decision boundary would enable gaming without genuine improvement (e.g. revealing exact score thresholds in adversarial contexts)
  • The changes required are entirely outside the user's control: showing them may produce frustration without any actionable value
  • The model is unstable and the counterfactual would not reliably hold (the same change might not produce the same result for a slightly different input)
  • Counterfactuals would expose sensitive model details, protected characteristics, or discriminatory patterns that should be addressed systemically rather than disclosed individually

Design

UI primitives

to be added soon
Content Block / Statement

Minimum change statement

A plain-language sentence describing the smallest change that would have altered the outcome: "If your debt ratio had been below 35%, this application would have been approved." Simple, direct, and actionable.

to be added soon
Content Block / Card

Counterfactual comparison card

A side-by-side card showing the current profile vs. the counterfactual profile: with the changed factors highlighted. Users can immediately see what's different.

to be added soon
Data Visualization / Visualization

Threshold visualization

A simple visual showing where the current score sits relative to a decision boundary, and how far it is from a different outcome. A number line, progress bar, or gauge can make the proximity to the threshold visible without revealing the exact threshold number.

to be added soon
Content Block / Card

Multi-factor counterfactual

Some decisions require changes to multiple factors simultaneously. A counterfactual explanation that shows "changing factor A and factor B together would change the outcome" is more honest than implying a single-factor change is sufficient.

to be added soon
Data Visualization / Highlight

Near miss highlight

A specific version of the counterfactual for borderline cases: "This application came close: 3 of 5 key criteria were met. The two factors that were not met are: [X] and [Y]." Particularly useful for motivating reapplication.

to be added soon
Data Visualization / Comparison

Controllable vs. fixed factors

A visual distinction within the counterfactual between factors the user can actually change and factors that are fixed (age, historical records). This is the bridge between counterfactual and recourse.

How to use

Lead with the change that is most plausible and controllable.

The mathematically minimal change is not always the most useful counterfactual. A change that is theoretically minimal but practically impossible is not helpful. Prioritize counterfactuals that are actionable.

Use plain language for the counterfactual statement.

"Had your income-to-debt ratio been 0.43 instead of 0.51" is less useful than "if you were paying €200 less per month in existing debt."

Be honest about multi-factor dependencies.

If changing one factor alone would not have changed the outcome: if two or three factors would need to change together, say so. A counterfactual that implies a single change would suffice when it wouldn't is misleading.

Don't present counterfactuals as guaranteed outcomes.

A counterfactual describes the model's decision boundary at the time of the decision. It is not a promise that making that change will produce a different result in a future application (model versions change, other factors shift). Use appropriate qualifying language.

Pair immediately with recourse.

The natural user response to a counterfactual is "so what can I do?" Don't let counterfactuals be a dead end: connect directly to Actionable Recourse.

Use cases

flow a

Understanding a borderline decline

  1. 1. Applicant sees their declined decision.
  2. 2. Below the attribution: "What would have changed this?" section.
  3. 3. System shows: "If your monthly debt payments had been €150 lower, the application would have been approved."
  4. 4. Applicant clicks through to: "How can I improve this?": recourse section explains debt reduction options and reapplication timeline.
flow b

Caseworker assessing an edge case

  1. 1. Caseworker reviews a case at the exact threshold: score 48, referral threshold 50.
  2. 2. Counterfactual panel shows: "This case is 2 points below the approval threshold. The closest factor to the boundary is employment verification: if confirmed by a third-party source, the score would reach 52."
  3. 3. Caseworker requests employment verification before making the override decision.
flow c

Multi-factor case

  1. 1. Applicant with several borderline factors asks what would change the result.
  2. 2. System shows: "No single factor change would change the outcome. However, if both of these changes were in place: [income ratio below 38%] AND [employment gap under 6 months], the application would be approved."
  3. 3. Applicant understands the full picture and assesses whether both changes are achievable.

Design trade-offs

Transparency vs. gaming

Counterfactuals reveal the decision boundary. In contexts where users could manipulate their inputs to cross a threshold without genuine improvement (e.g. staging financial documents), this is a real risk. Consider showing direction without precise thresholds, or scoping counterfactuals to user-facing recourse channels rather than raw system access.

Helpfulness vs. false promise

A counterfactual implies: "if you change this, the outcome will be different." But models are not deterministic across applications, and policies change. Use qualified language and a clear disclaimer about what the counterfactual does and doesn't guarantee.

Simplicity vs. completeness

The simplest counterfactual is a single-factor change. But many real decisions have complex multi-factor boundaries. Showing only the simplest counterfactual when multiple changes are required is misleading. Acknowledge complexity.

Connections

Relation to other patterns

Attribution and counterfactual explanation are complementary. Attribution answers "what mattered." Counterfactuals answer "what would have changed it." Together they form a complete explanation.

The "near miss" counterfactual case is also a form of example: a real or illustrative case that was similar but different in outcome. The patterns reinforce each other.

Sources

introduces counterfactual explanations as a legally grounded approach to explaining algorithmic decisions. The paper directly motivates the GDPR-aligned use of counterfactuals for adverse decisions

makes the critical distinction between counterfactuals (what would change the outcome) and recourse (what the person can actually do). Essential for designing honest counterfactual interfaces

proposes recourse as a measurable property of classification systems and develops methods for identifying actionable changes. Provides the technical basis for distinguishing controllable from non-controllable factors in the counterfactual display