Should smart homes keep an inference ledger?

I’d like ambient devices and wearables to expose an inference ledger, not just a sensor log. If a system concludes “probably asleep,” “working from home,” or “emotionally stressed,” I should see the inference, timestamp, source sensors, confidence, retention period, and every app or service that received it.

Those conclusions can be more intimate than the measurements that produced them. The awkward design question is what happens when the raw audio, motion, or heart-rate data is already gone. I think the inference should remain independently correctable, annotatable, revocable for future use, and deletable, with corrections or deletion propagated downstream where possible. Otherwise deleting the source only creates the appearance of control.

Would you actually inspect a ledger like this? Which controls are essential, and which would become unreadable dashboard clutter?

The ledger needs a lineage graph, not just prose labels. “Probably asleep” may depend on motion, light, phone charging, and a model version. If the UI hides that dependency, confidence becomes decorative. I’d also want to know whether the inference was used before I corrected it.

The correction point is stronger than it may first appear. EDPB guidance treats opinions and inferences, including profiling, as data that can be rectified. A raw-data deletion workflow is therefore not an adequate substitute if the derived conclusion is still retained or used.

I’d inspect it once, then probably rely on defaults unless something looked wrong. That argues for alerts around high-impact inferences rather than a permanent spreadsheet. “Shared with three services” is useful; a hundred model metadata fields probably isn’t.

A ledger is also a sensitive asset. It could become a beautifully searchable catalog of someone’s sleep, stress, routines, and absences. Local storage, strong access control, and an export/delete path matter as much as the visibility feature. Transparency that creates a new breach target is not free.

The wording matters. “Emotionally stressed” sounds like a diagnosis even when it is only a weak guess. I’d want the interface to show uncertainty and let the user replace the label with “don’t know,” not force a more precise answer than the system earned.

If the raw events are discarded, the ledger should still carry enough provenance to challenge the result without reconstructing the events. A signed record of model version, inputs by category, and downstream destinations could work. Keep the detailed sensor history local or ephemeral.

I’m not convinced “delete the inference” is always coherent once a service has acted on it. You can remove the stored label, but you may not be able to unmake a decision. The ledger should show consequences and recipients, while being honest about what reversal can and cannot do.

Propagation is where this becomes an operations problem. “Delete everywhere” needs acknowledgements, retries, and a record of which recipient failed. Otherwise the button is just a promise. I’d prefer a visible status such as deleted, pending, or unable to verify.

I would inspect it if the system gave me a reason. A monthly “here are the sensitive conclusions we made” report is more realistic than asking people to browse telemetry every evening. Make the controls boring and obvious. That would already be an improvement.

Please don’t call confidence a percentage unless it has a defensible meaning. “0.82 stressed” invites false precision. Show the evidence categories, uncertainty, and what threshold triggered sharing. Otherwise the ledger merely gives bad guesses a nicer UI.

For deployments, I’d need an audit trail of the user’s correction and the recipient notifications, with retention rules that are themselves visible. The hard part is not displaying an inference; it is proving that downstream systems stopped relying on it.