Curiosity should not become a permanent recommendation signal

Recommendation systems should distinguish deliberate preference from ambiguous behavior. Following, saving, or giving a rating is a fairly clear signal; clicking in outrage, arguing in comments, or pausing to verify a claim is not. Yet I worry that controversy and curiosity can quietly become part of the profile a feed keeps using.

I’d like a visible “don’t learn from this interaction” control, with scopes for this item, this session, or permanently. Better still, users should be able to inspect which actions currently influence their feed, rather than trusting a vague privacy label. YouTube already lets people pause or delete watch and search history, but that is broader than excluding one interaction; TikTok documents several feed controls, not this exact feature.

The control could be gamed or make recommendations worse. Would it improve personalization, or just create another misleading privacy promise? Concrete examples from existing platforms or better designs welcome.

The key implementation question is whether “don’t learn” applies to the event, the content cluster, or the inferred feature derived from it. Deleting one raw click is not enough if a model has already folded it into an interest vector. The UI needs to describe the boundary plainly.

I like the distinction, but I would avoid claiming that these interactions are definitely durable identity signals on named platforms. The evidence supports that watch history and other engagement can affect recommendations; it does not establish the full lifecycle of a rage-click.

A one-tap exclusion is attractive, but most people will not manage a ledger of every accidental click. I’d make the default protection automatic for short sessions around a topic, then ask whether the user wants to keep that interest. Fewer controls, better timing.

“Don’t learn” also needs a retention promise. If the platform keeps the event for fraud, safety, or debugging, that is different from using it for recommendations, but users should not have to infer the distinction. Separate purposes, separate labels.

The wording matters. “Don’t personalize from this” is more honest than “private,” because the latter invites people to assume the activity disappears everywhere. I’d put it beside the like and save actions, not bury it in account settings.

There is a cost to treating every negative signal as noise. Someone who watches an entire rebuttal, checks several sources, and returns tomorrow may genuinely want more material. A temporary research mode seems safer than permanently discounting the behavior.

A visible influence audit would be useful, provided it says “main signals” rather than pretending to expose an explainable neural autobiography. The shorter and more concrete the list, the less likely it becomes another decorative transparency screen.

I’d prefer a local preference journal: the client records explicit inclusions and exclusions, while the server receives a limited recommendation policy. That will not solve every inference problem, but it reduces the need to trust a dashboard describing a black box after the fact.

Support teams would need an undo path. People will hit the control accidentally, then report that their feed became strangely narrow. “Exclude for 24 hours,” “exclude this topic,” and “restore default” are more operationally realistic than one permanent switch.

I’d test this against a simple baseline: explicit follows and ratings count; clicks and comments expire quickly unless reinforced. If the quality drop is small, that is probably a good trade. If quality collapses, the promise needs to be narrower, not louder.