Remembered preferences must be inspectable and resettable

What it is

Users should see which modality preferences are remembered, what context and evidence they come from, and whether they were explicit or inferred; they should be able to edit, delete, or reset them. Inspection and reset are prerequisites for trust and repair, not settings-page decoration.

Why it happens

The memory model is usually invisible to users. When it records wrongly, the system keeps recommending an unsuitable channel; without a diagnostic view, users only repeat manual switching or abandon the feature. An auditable record makes hidden state discussable: context keys, channel combination, evidence type, confidence, last use, and expiry. Reset also needs layers—delete one wrong place, clear a device, turn off inference, or restore factory defaults—because different error sources need different repairs. For inferred memory, explaining “why this was remembered” prevents the error from persisting better than showing only the result.

Studying it

Use usability tests and audit logs: show correct and incorrect memories, then measure whether users find records, understand evidence, complete single deletion, bulk reset, and post-reset verification. Variables include record granularity, explanation wording, entry depth, bulk operations, and shared-device mode. Outcomes include time, errors, perceived control, accidental deletion, and privacy concern. Also track which real preferences are inspected or reset; frequent resets usually indicate a learning-model or scope problem.

Where it stops holding

Exposing every internal feature becomes a technical log that ordinary users cannot read; oversimplifying prevents locating the error. Explanations should use perceivable context language (“when headphones are connected at work”), not feature vectors. Shared devices, family accounts, and work accounts need rules for who may view or clear whose preferences; some organizational policies may reserve reset for administrators. After reset, the system should return to a predictable default rather than immediately infer from residual caches.

Applying it

• Provide a preference list showing context, channel, source, confidence, and last use, with single-item deletion.
• Offer bulk reset, learning off, per-device/place clearing, and restore defaults; show results before and after each action.
• Explain inferred evidence with example events and let users correct the record directly from that explanation.
• Verification: ask users to repair a known wrong memory, then measure success and time across discovery, understanding, deletion, and verification.

Related

• Within the group: D5.11.1 The system may remember modality preferences in specific contexts · D5.11.2 Preferences should change with context rather than apply to every situation
• Adjacent: D5.09.4 After explicit switching, do not silently return to the default · D5.11.4 Overreliance on historical preference delays response to current environmental change
• Search terms: preference audit · reset memory · model transparency