Reasons make recommendations rebuttable, so users can correct a wrong profile

What it is

“Because you like jazz” is not only an account. It is a handle: the user can say “I do not like jazz.” Rebuttable recommendations make the ranking basis a proposition that can be denied, after which the profile and later lists must follow. A recommendation without a handle can only be endured or left; it cannot be corrected.

Rebuttal targets the basis, not “don’t like this item.” Item-level negative feedback is a different channel.

Why it happens

With no visible basis, the user faces results and can only guess at a fix: show less of this class, delete history, wait. A reason pulls one corner of internal state onto the operable layer, so correction becomes propositional — deny P, and the system should not keep using P. That needs reason and scoring feature on one rope: if denying the copy only changes the sentence, rebuttal is theatre.

Rebuttability also constrains what a reason should say. More specific, more accurate the handle; empty talk or a post-hoc story, and denial has nowhere to grip. Tracking leakage is the cost of the handle: when specificity becomes uncomfortable, people may skip rebuttal and just turn the whole thing off. Design has to leave an operable grain between “can grip” and “do not narrate surveillance too finely.”

Studying it

Give a reason with a wrong basis (the system claims a class the person clearly dislikes), with or without a “not because of this” control. Measure: whether they can name the proposition to deny, whether exposure of that class drops after denial, whether the drop holds in later sessions. Independent variables: whether the reason points at a real feature, whether the control binds the feature rather than only this row. Dependent variables: correction success, return of the class, collateral damage (unrelated classes removed too).

If after denial only this row vanishes and the class remains, the handle is wired to the item, not the profile. That is item deletion, not a rebuttable recommendation.

Where it stops holding

Ad slots and legally required rows are often not rebuttable; label them “promoted” rather than dressing them as a deniable taste. Rebuttal on someone else’s account (shared device) writes into the wrong file and needs account confirmation. This entry wants the reason to be a correction entry. It does not treat the emotional semantics of negative feedback, and it does not treat turning personalization off.

Applying it

• Beside every reason that points at the profile, put “not because of this.” It should void that basis and block reuse for a period, not merely pull this row from the list.
• The correction must be visible on the next screen: the class drops, and reasons stop citing the denied proposition.
• Check: give a test account a wrong-class reason and walk through rebuttal. Exposure of that class over the next two days should fall. If only one row is gone and the class remains, the entry is fake.

Related

• Same group: L6.07.1 A reason helps the user decide whether an item is worth opening, not to persuade them to open it · L6.07.2 Reasons must come from the actual ranking basis; a post-hoc story is another kind of hallucination · L6.07.3 Reasons expose data sources and can make users feel tracked · L6.07.5 The same sentence on every item conveys no information
• Nearby: L6.13 Negative Feedback Channels for Recommendations · L6.10 Turning Personalization Off and Resetting It · L6.06 Inferred Preferences and Their Limits
• Search terms: rebuttable recommendations · why as handle · correcting the profile