Correction feedback

Problem Context

• A user may need to correct a factual answer, cited source, generated recommendation, tool-derived value, safety-sensitive suggestion, outdated policy answer, tone, scope, or missing caveat.
• The same feedback can mean apply a fix to this answer, avoid repeating the behavior, route to a reviewer, improve retrieval sources, update prompt instructions, improve model data, or simply record user dissatisfaction.
• Feedback may contain private, sensitive, regulated, customer, patient, legal, financial, or internal business information that must not appear in shared transcripts or training data without consent.
• AI corrections are valuable only when they preserve answer ID, claim span, source ID, conversation context, model response version, user reason, expected answer, and outcome.
• Some corrections require human review, audit trails, appeals, retention limits, or disclosure that the current answer will not change immediately.

Selection Rules

• Choose correction feedback when users need to correct AI output, source use, assumptions, recommendations, safety behavior, or answer quality after an AI response is shown.
• Use query correction when the product rewrites or suggests a search query before results are returned.
• Use inline validation when the product flags a single form field, input value, format, or constraint violation.
• Use comments when the main task is human discussion, annotation, approval, or durable collaboration around an object rather than feeding back to an AI system.
• Use regenerate / retry when users want another AI attempt or response version without necessarily supplying a correction reason.
• Use editable AI output when users directly edit the generated draft itself and need change tracking or apply controls.
• Use source grounding display, citation display, or confidence uncertainty display when the task is inspecting evidence or uncertainty rather than sending a correction.
• Capture selected answer, selected claim, selected source, feedback reason, expected answer, corrected source, privacy note, scope, consent, and receipt before treating correction feedback as actionable.
• Do not use thumbs-only, sentiment-only, star rating, or undifferentiated reaction controls as the only path for correcting materially wrong or unsafe AI output.
• Do not silently train on correction text, rewrite hidden prompts, publicize private notes, or imply the current answer changed unless the user can see the corrected output.

Required States

• Initial AI answer state with feedback entry points attached to the answer, individual claims, citations, recommendations, or tool-derived values.
• Wrong answer, missing source, wrong source, harmful suggestion, outdated answer, irrelevant answer, biased or unsafe answer, hallucinated value, and incomplete answer reasons.
• Selected claim, selected source, expected answer, corrected source, private note, attachment, and reviewer-needed states.
• Scope choices such as apply to this answer, apply to future answers, review only, update source, do not train on this feedback, and keep feedback private.
• Submitting, feedback received, failed to submit, duplicate feedback, queued for review, accepted, rejected, partially applied, appealed, and feedback history states.
• Permission, authentication, rate limit, abuse-prevention, moderation, sensitive-data warning, and retention-disclosure states.
• Mobile correction sheet state that keeps the selected claim, reason, scope, consent, and receipt visible without losing the answer context.

Interaction Contract

• A correction feedback action preserves answer ID, response version, claim span, source ID, user reason, expected correction, submitter, timestamp, and chosen scope.
• Reason choices remain specific enough to route feedback: wrong answer, missing source, wrong source, outdated answer, harmful suggestion, unsafe or biased output, irrelevant answer, and other correction.
• Users can add expected answer text, corrected source, or a private note, and the UI states which of those fields may be used for review, source improvement, prompt improvement, model improvement, or current-answer repair.
• Scope controls distinguish this answer, future answers, reviewer triage, source update, and training use; defaults must not hide consequential data use.
• Submission creates an accessible receipt and a visible follow-up path when review or appeal is possible.
• Private feedback does not appear in shared transcripts, public comments, copied output, generated summaries, or source snippets unless the user explicitly publishes it.
• If a correction changes the displayed answer, the UI shows the corrected version, prior version, author or reviewer status, and what changed.
• If the correction cannot change the answer, the UI says so and avoids implying immediate model learning.

Implementation Checklist

• Model correction feedback with answer ID, response version, claim span, source ID, tool output ID, reason, expected answer, corrected source, private note, scope, consent, status, reviewer owner, and history fields.
• Provide claim-level selection and source-level selection so users do not have to describe what the correction refers to in free text alone.
• Route wrong answer, source correction, harmful suggestion, outdated answer, missing source, and sensitive feedback to different handling paths when product risk requires it.
• Persist feedback receipts and outcomes so users and reviewers can see whether a correction is queued, accepted, rejected, partially applied, appealed, or closed.
• Keep training consent, privacy controls, retention language, and shared-transcript behavior explicit before submission.
• Prevent duplicate submissions, lost feedback, cross-answer attribution, public leakage, hidden prompt edits, and unreviewed automatic current-answer changes.
• Test desktop and mobile correction capture, selected claim wrapping, long corrected source titles, private note handling, disabled submit states, failed submission recovery, review status, appeal, keyboard operation, and screen-reader status announcements.

Common Generated-UI Mistakes

• Using a thumbs-down or smiley reaction as the only mechanism for correcting wrong AI output.
• Collecting feedback without tying it to a specific answer, claim, citation, source, tool result, or response version.
• Hiding whether feedback applies to the current answer, future answers, review queues, training data, retrieval sources, or prompt behavior.
• Treating correction text as a new prompt or hidden instruction without showing the user that the answer scope changed.
• Publishing private correction notes in a shared transcript or training on them without consent.
• Confirming receipt with no durable status, reviewer outcome, appeal path, or feedback history for high-risk corrections.

Critique Questions

• What exact answer, claim, source, recommendation, or tool result is being corrected?
• Can the user state whether the problem is wrong answer, missing source, wrong source, harmful suggestion, outdated answer, biased output, or another correction?
• Does the user know whether the correction affects this answer, future answers, review only, source quality, prompt behavior, or training use?
• Where does private correction text appear, and what prevents it from leaking into shared transcripts or generated output?
• What receipt, status, reviewer decision, appeal path, or history can the user inspect after submission?
• Would query correction, inline validation, comments, regenerate / retry, or editable AI output better match the real task?