How can I challenge this decision?
Surfaces when a client's 'contact us' form is the only appeal path for automated decisions, or when a regulator asks for evidence that affected people have a meaningful right to challenge outcomes.
When an AI system makes a decision that affects someone's life, whether access to credit, benefits, employment, or housing, that person has a right to challenge it. Not just a user experience expectation: a legal right, codified in GDPR Article 22, the EU AI Act, and consumer protection law in numerous jurisdictions.
Contestability is the design pattern that makes this right exercisable. The right to contest an automated decision means nothing if there is no clear path to do so: no button, no form, no person to contact, no mechanism for the challenge to be received and acted upon.
This pattern is distinct from Human-in-the-Loop, which is exercised within the process by an authorized operator. Contestability is exercised by the person affected, from outside the process, after a decision has been made. It is a right of redress, not an operational review mechanism.
It is also distinct from Actionable Recourse, which tells users what they can change to get a different result in a future decision. Contestability is about challenging the specific decision that was made: asserting that it was wrong, unfair, or based on incorrect information.
Provide a clear, accessible, and functional mechanism through which the person affected by an AI-influenced decision can formally challenge it: with confidence that the challenge will be received, reviewed by a human, and result in a documented response.
A clearly labelled, persistent action available after any adverse decision: "Challenge this decision" or "Request review." Not buried in a footer or help section. Visible at the decision result screen.
A structured form with: - Reason for challenge (dropdown + free text) - Ability to upload supporting documents or evidence - Contact information for follow-up - Submission confirmation with a reference number
Immediately after submitting a challenge, provide a clear explanation of the review process: who reviews it, what the timeline is, what the possible outcomes are. Reduces anxiety and sets expectations.
After submission, a status view showing where in the process the challenge is: - Received - Under review - Decision pending - Resolved
An explicit statement that the challenge will be reviewed by a human, not re-processed by the same automated system. This is the core of meaningful contestability.
If the first-level review is unsatisfactory, information about further escalation, whether an ombudsman, a regulator, or a court, is made visible. Users should not have to research this independently.
A user who just received a declined application or a flagged content decision is in the moment of highest motivation to understand and challenge. The path to contest must be there, now, not discoverable only after a search.
If applying took 10 minutes and challenging requires a 20-page form, the contestability mechanism is not functional. Simplify the challenge path to the minimum needed for a substantive review.
An appeal processed by the same automated system that made the original decision is not a review. It is a repetition. Contestability requires that a person: a human being: reviews the challenge.
Tell users when they can expect a response. Then meet that timeline. Unresolved challenges with no updates are worse than no challenge mechanism at all.
Every challenge submitted is a data point about system performance: where users believe the system was wrong. This data should be systematically collected and used to improve the system. See Feedback Loops and Audit Trail & Logging.
Access vs. gaming
An open challenge mechanism may be used by some users to delay decisions or game the process. Design for proportionality: low-effort challenge path for genuine errors; escalation path for complex disputes. Don't restrict the challenge mechanism because of a minority of bad actors.
Genuine review vs. performative compliance
Regulators require contestability. Some organizations build challenge mechanisms that technically satisfy the requirement but have no real review process behind them. This is worse than honest disclosure that review resources are limited. Design for genuine reviewability or be explicit about resource constraints.
Speed vs. thoroughness
A 5-day review timeline is usable. A 6-month timeline is not. Design review processes and challenge mechanisms in conjunction: the design of the interface is only as good as the operational process behind it.
HITL is exercised by operators within the process. Contestability is exercised by affected persons after the decision. Both are oversight mechanisms but serve different roles.
Recourse helps users change the inputs to get a different future outcome. Contestability challenges the specific past decision. They address different goals and should be clearly distinguished in the interface.
Every challenge must be logged. The audit trail is the foundation for meaningful review.
Providing the decision timeline to the person challenging the decision helps them understand what happened and build a substantive case.
Lakkaraju et al. (2020) — Algorithmic Recourse
examines the relationship between explanation and recourse in algorithmic decision systems. Distinguishes recourse (changing future outcomes) from contestability (challenging past decisions)
European Union (2016) — General Data Protection Regulation (GDPR). Article 22
the primary legal mandate for human review of automated decisions and the right to contest
European Union (2024) — EU AI Act, Article 14
extends human oversight requirements to high-risk AI systems
Kroll et al. (2017) — Accountable Algorithms
argues that algorithmic accountability requires not just transparency but contestability: a mechanism for challenging decisions through a process that is itself auditable