Takeovers should be recorded to improve future judgements

What it is

Takeover events should be recorded: who, when, in what context, halted what, and what the system did next. The record serves two offices — forward as data for improvement (the situations in which users take over are precisely where the inference model most needs work), and backward as an inspectable evidence chain ("why did it start doing that last week" — because you skipped that reminder three times on Tuesday).

Division of labour with the learning entry in this family: that one covers the principle of learning (overrides are training signals); this one covers the infrastructure of records (learning must have books to audit). Learning without records fails both ways: on the improvement side there is no data to learn from; on the audit side, users cannot tell what the system has learned from them — and learning about someone in the dark is worse than not learning at all.

Why it happens

Takeovers are high-value training samples. The moment a user takes over is the moment inference and reality visibly diverge — the system thought it should act, the user said no. Divergence samples carry more information than compliance samples: compliance only says "perhaps right"; a takeover pinpoints "wrong here". Feeding structured takeover records (context, action, method, aftermath) back into the improvement loop lets users do, unpaid, the most expensive kind of annotation.

The record is also a trust ledger. If a behavioural change traces back to specific takeover records ("the morning reminder was disabled after you skipped it repeatedly"), the change reads as caused rather than capricious — an intact attribution chain is trust's hard currency. Changes that trace nowhere read as drift and get interpreted at worst.

Records carry their own privacy tension. Takeover logs contain behavioural information (when home, what matters, what annoys whom), which makes the log itself sensitive data — storage location, retention period, and readability must be designed together with the record's value, not patched on afterwards.

Studying it

• Feedback-value research in interactive machine learning: the value of human feedback samples is unevenly distributed — corrective feedback (skips, interruptions, re-does) is denser in information than compliant feedback; this is a repeatedly confirmed consensus, and takeover records are corrective feedback par excellence.
• Practice evidence from consumer systems: skips, interruptions, and repeated commands on smart speakers and assistants are widely used as dissatisfaction signals for product improvement (standard practice in that space, described generically).
• Method: paired deployments — with a takeover-record feedback loop versus without — measuring subsequent takeover rate and misjudgement rate; experiments on record readability's effect on trust (can versus cannot view "what was learned").

Where it stops holding

• The record's value presupposes a live improvement loop. A log that never feeds improvement is compliance decoration; conversely, a log that feeds improvement but is never shown to users is learning in the dark. Both failure modes must be avoided — record, improve, and inspect come as a set.
• Takeover is not always dissatisfaction. Some takeovers are collaboration ("skip the heating today"); some are reactions to faults — learning every takeover as a negative sample points the model the wrong way; the record must retain enough context for the improvement stage to tell them apart.
• Ownership in multi-user homes. Whose takeover, improving whose model — with unclear attribution, learning averages across everyone and satisfies no one.

Applying it

• Structure the record: log the full six-tuple per takeover — time, trigger context, action halted, stop method, system behaviour after, whether it resumed — enough to replay the event completely.
• Make records readable and deletable: users can see a "what the system learned from my actions" list, entry by entry removable ("stop learning anything from my evening lights-out").
• Make the improvement loop visible: behaviour adjustments driven by takeover patterns get announced ("weekday morning reminders disabled after repeated skips on weekday mornings").
• How to check: sample takeover events and verify the record alone suffices to replay the situation and decision; sample learned changes and verify each traces back to concrete takeover records — improvements whose trail disappears into the dark do not ship.

Related

• Same group: Z3.06.1 Users must be able to stop an automation action while it runs · Z3.06.2 After a takeover the system must not silently resume its previous behaviour · Z3.06.3 The edit entry point belongs where the outcome appears
• Nearby: Z3.04.3 Overrides should be learned by the system · Z5.03 Tracing causes
• Search terms: takeover logging · feedback loop · corrective feedback · interactive machine learning