Explainables
Created with the help of AI
Category — Act

Actionable Recourse

user agencycausal reasoninginteractive inquiry
User question

What can I do to change this outcome?

Consulting signal

Relevant when clients want to go beyond 'we explained the decision' to 'we helped the user understand what they can do about it.' Also surfaces in contexts where adverse decisions must include information about appeal and improvement paths.

Overview

Why this pattern exists

Explanation without recourse is a verdict. Users who understand why they were declined but can do nothing about it are not better off than users who were simply told no. Understanding the past is only valuable when it can inform action toward a different future.

Actionable Recourse is the pattern that bridges explanation and agency. It takes the factors that drove an adverse decision and translates them into practical, realistic steps the user can take to change the outcome: distinguishing what is genuinely within their control from what is not.

This is harder to design than it sounds. The technically correct counterfactual (the minimum change that would cross the model's decision boundary) is not always the practically actionable recourse (the change that is realistic, controllable, and achievable for this specific person). A loan recourse that suggests "reduce your monthly debt payments by €400" is only useful if that is actually feasible for the user.

Good recourse design requires honesty about what is and isn't controllable, specificity about what is needed, and a realistic estimate of the path.

Design goal

Translate the factors behind an adverse AI decision into specific, realistic, controllable next steps: giving users a genuine pathway to a different outcome rather than a list of features to optimize.

Usage guidance

When to use

  • The decision was adverse and the user has a legitimate interest in a different future outcome
  • Some factors in the decision are within the user's control
  • The interface supports re-application, re-evaluation, or appeals workflows
  • Legal requirements give users a right to meaningful information about, and human review of, automated decisions (GDPR Article 22 and Recital 71)
  • The goal is to empower users, not just explain the system

When not to use

  • All factors that drove the adverse decision are entirely outside the user's control: recourse should not be shown when it cannot exist
  • Showing recourse paths would enable fraudulent optimization (gaming) of the system without genuine improvement
  • The decision is not adverse: recourse is for situations where the user wants to change the outcome
  • Recourse would create false hope by presenting as achievable something that is statistically very unlikely

Design

UI primitives

Content Block / List

Recourse action list

A structured list of specific actions, organized by: - What you can change (controllable factors) - What you cannot change (fixed factors: shown honestly) - What the organization can do (additional review, data correction, verification) Each item includes: what the action is, why it would help, and what evidence or documentation is needed.

Inline Signal / Indicator

Impact indicator

A signal showing the relative impact of each recourse action: - High impact: would substantially change the outcome - Medium impact: would improve the score but may not be sufficient alone - Low impact: contributes marginally Prevents users from investing effort in low-impact changes while missing high-impact ones.

Inline Signal / Indicator

Time estimate

For each recourse action: a realistic estimate of how long it would take to implement. "Reducing debt ratio typically takes 3–6 months" is more useful than just "reduce debt."

Navigation & Flow / Flow

Document request flow

When recourse involves providing documentation (income verification, corrected records), an integrated upload or submission flow, not a dead-end instruction to "contact us."

Data Visualization / Timeline

Recourse timeline

A visual showing the sequence of steps and timeline: "Submit documents now → Re-evaluation in 5 days → Decision." Reduces anxiety by making the path visible.

Content Block / Section

Cannot change section

An honest display of factors that are fixed and cannot be changed by the user: age, historical records, certain credit events. Showing what cannot be changed is as important as showing what can: it prevents users from wasting effort on dead ends.

How to use

Separate controllable from non-controllable factors explicitly.

This is the most important structural decision in recourse design. A list of "factors that affected your decision" that includes both changeable and unchangeable factors without distinguishing them is not recourse: it is confusion.

Be specific, not general.

"Improve your credit score" is not actionable. "Reduce your total monthly debt payments below €600 and maintain this for 3 months" is actionable. Specificity requires knowing what the threshold is: which may mean providing information the system would otherwise keep internal.

Use realistic impact estimates.

If changing one factor alone is insufficient to change the outcome, say so. Recourse that implies "do X and the decision will change" when X alone is not sufficient creates false expectations.

Link recourse directly to the document submission or re-application process.

Every "what you can do" item should end with a clear action, not an instruction to go somewhere else.

Avoid recourse that enables gaming without genuine improvement.

Recourse should reflect factors that are genuinely relevant to the decision, not just model features that can be manipulated. Be especially careful in contexts where gaming could harm other users or undermine the decision's purpose.

Use cases

flow a

Loan applicant seeking a path forward

  1. 1. Applicant receives a declined loan decision.
  2. 2. Attribution panel shows top factors.
  3. 3. Below attribution: "What you can do" section.
  4. 4. "High impact: Provide income verification: your income could not be verified from the documents submitted. [Upload documents]"
  5. 5. "Medium impact: Reduce monthly debt obligations below €550. Your current level is €680. This may take 3–6 months."
  6. 6. "Cannot change: The credit default recorded in 2021 is fixed and cannot be removed."
  7. 7. Applicant uploads income documents. Case re-evaluated in 3 days.
flow b

Employment screening challenge

  1. 1. Applicant is flagged in a pre-screening process.
  2. 2. Recourse section: "The following items were flagged and can be addressed: an employment date that could not be verified, and a certification that has expired. Upload a current employment confirmation and the renewed certificate to resolve them."
  3. 3. Applicant submits updated materials.
  4. 4. Case moves to human review with updated information.
flow c

No actionable recourse available

  1. 1. Applicant receives a declined decision.
  2. 2. System determines that all contributing factors are fixed (credit history, existing defaults).
  3. 3. Recourse section shows honestly: "At this time, the factors that affected this decision cannot be changed. The earliest you could reapply with a meaningfully different profile is [date range]."
  4. 4. Applicant is not given false hope, but is given a timeline and contact for further questions.

Design trade-offs

Transparency vs. gaming

Specific recourse information reveals model decision thresholds. In some contexts, this enables users to optimize for the model without genuine improvement (e.g. temporarily suppressing debt before an application). Consider showing direction without precise thresholds when gaming risk is significant.

Helpfulness vs. false promise

Recourse suggests that taking action will change the outcome. This is not guaranteed: policy changes, model updates, and other applications may intervene. Use qualified language: "following these steps is likely to improve your assessment" rather than "will result in approval."

Specificity vs. scope of disclosure

Very specific recourse requires disclosing model thresholds or internal scoring logic. Determine the appropriate level of disclosure for your context: regulatory, commercial, and ethical factors all apply.

Connections

Relation to other patterns

Sources

proposes recourse as a measurable, designable property of classification systems. Introduces the distinction between counterfactual changes and actionable recourse: changes that are actually controllable and realistic

the foundational paper connecting counterfactual explanation to legal rights under GDPR. Establishes that counterfactuals/recourse are a legal as well as a design requirement for consequential automated decisions

makes the critical argument that counterfactual explanations are necessary but not sufficient for genuine recourse. Recourse must also account for causal feasibility and user agency. The theoretical basis for the controllable/non-controllable distinction in this pattern

Explainables
Created as a side project by Christian Laesser & AI