How can I correct the system?
Comes up when a client wants to improve model quality over time using real user experience, or when they need to demonstrate to a regulator that errors are being captured and addressed.
AI systems are not finished when they are deployed. They encounter new situations, make mistakes, and degrade over time as the world changes. The people best positioned to identify these problems are the ones using the system, and the people most affected by its mistakes are the ones subject to its decisions.
Feedback Loops is the pattern that connects users' experience of AI outputs back to the people responsible for the system. Not feedback as a compliance gesture ("we value your input"), but feedback as a genuine data pipeline: corrections, disagreements, and error reports that are collected, reviewed, and acted upon.
The design challenge is two-fold. First, the feedback mechanism must make it easy for users to signal when something is wrong: without requiring technical knowledge or significant effort. Second, it must be honest about what happens with feedback: closing the loop so users know their input was received and, where possible, what changed.
This pattern also addresses a subtler problem: feedback systems that collect input but never act on it erode trust faster than no feedback system at all. Users who submit corrections and receive no acknowledgment conclude that the system doesn't care. Design for the whole loop, not just the submission step.
Provide a low-friction mechanism for users to report errors, provide corrections, and signal disagreement with AI outputs, and close the loop by communicating that feedback was received and, where appropriate, how it was used.
The minimum viable feedback mechanism: a binary signal on a specific output. Appropriate for low-stakes or high-volume contexts where nuanced feedback is not feasible. Only use where the binary signal is genuinely informative.
An input field allowing users to provide the correct information alongside the error flag: "The AI said X. The correct answer is Y." Most valuable for systems where factual corrections are possible (entity recognition, data extraction, classification).
A structured dropdown of feedback categories: - Factually incorrect - Based on outdated information - Missing relevant context - Biased or unfair - Unclear or confusing - Other Structured reasons are more actionable for the review team than free-text alone.
After submission: a confirmation message that sets realistic expectations: "Your feedback has been received. We review all submissions weekly. This specific output may be updated in a future model release."
When a user's feedback results in a system change, whether a correction or a model update, send a notification: "Based on feedback like yours, we updated [X] on [date]." Rare but powerful for trust-building.
For transparency-forward systems: a public or accessible view of the volume and categories of feedback received, and what actions were taken. Demonstrates that the feedback loop is genuine.
A feedback button that leads to a database no one reads is a trust-destroying pattern, not an explainability pattern. Design the feedback collection in conjunction with the review and update process.
Research in participatory AI identifies a failure mode where feedback collection functions as a performance of responsiveness rather than a genuine data pipeline: systems that ask for input to appear accountable without any mechanism for that input to change anything. Users who encounter this pattern, submitting feedback repeatedly with no visible effect, develop deeper distrust than users who were never offered a feedback mechanism at all. The design question is not "do we have a feedback button?" but "what is the path from this submission to a system change?"
A generic "contact us" link is not a feedback loop. Feedback should be anchored to the specific output, decision, or claim it concerns.
Users who submit feedback and hear nothing assume it was ignored. A simple confirmation message with a realistic timeline ("reviewed monthly") is significantly better than silence.
Even a periodic email, for example "we've reviewed 200 pieces of feedback this month and updated the following categories," is more trustworthy than silence. Individual notifications are ideal where feasible.
Design the data structure of feedback collection so it can be queried, analyzed, and used to improve the model or process. Unstructured text feedback is hard to act on at scale.
Participation vs. noise
Open feedback mechanisms can be flooded with low-quality or adversarial inputs. Design for signal quality: structured options, optional explanation, submission rate limits.
Transparency about use vs. managing expectations
Being honest about how feedback is used may reveal that individual feedback rarely leads to direct changes. Be truthful about timelines and probability of direct impact: users generally prefer honesty to false promises of responsiveness.
Individual correction vs. systemic improvement
Some feedback should fix this specific case immediately. Other feedback should improve the system for everyone. Design for both: immediate correction of individual errors where possible, and aggregated systemic improvement over time.
Contestability challenges a specific adverse decision. Feedback is a lighter-weight signal about output quality. Both contribute to accountability but at different intensity levels and with different processes behind them.
Feedback submissions should be logged alongside the original decision. The full record, including AI output, user feedback, and any subsequent correction, constitutes a meaningful audit trail.
User feedback can be a trigger for human review: "This output has received 5 feedback flags: route to manual review."
Feedback about biased or unfair outputs is one of the most valuable data sources for fairness monitoring. The two patterns are closely linked in governance-focused systems.
Amershi et al. (2014) — Power to the People: The Role of Humans in Interactive Machine Learning
establishes the theoretical and practical basis for human feedback as a mechanism for improving machine learning systems. Proposes that end users, not just data scientists, should be able to contribute corrections and signal errors. The foundational paper for this pattern. Published in AI Magazine, 35(4)
Birhane et al. (2022) — Participatory Machine Learning
argues that meaningful participation in AI systems requires more than feedback collection: it requires that affected communities have genuine influence over system design and governance. Motivates the "close the loop" design requirement
Raji et al. (2020) — Closing the AI Accountability Gap
makes the case that accountability requires not just auditing AI systems but creating mechanisms through which failures can be reported and acted upon. Directly supports the feedback-as-accountability framing