If the sensors are deleted, what happens to the inference?

When a home system combines wearable signals with ambient sensors, the useful output is often not the raw data but a label: “sleeping,” “stressed,” “alone,” or “likely to leave.” Those labels can quietly drive heating, lighting, or notifications. Deleting the underlying readings does not necessarily make the label harmless; if it relates to an identifiable household member, it may still be personal data. “Stressed” could also raise stronger concerns depending on how the system interprets and uses it.

I’d rather see an on-device inference ledger than another privacy toggle: record what was inferred, the inputs or rationale, purpose, confidence, authorized viewers, sharing history, and expiry. That makes the automation auditable without retaining every sensor stream. Do inferred states deserve stricter retention and sharing limits than ordinary event logs? I’m interested in disagreement or better designs.

The ledger is the right direction, especially if it is itself local and access-controlled. I would separate “used for automation” from “available for inspection”; a household member may need to see why the heating changed without exposing another person’s inferred state.

Convenience is real here. People do want the lights and temperature to follow the household without constant configuration. The product challenge is making expiry and explanation invisible most of the time, but easy to find when something feels wrong.

A ledger is not automatically a safeguard. It becomes a second sensitive database, with sharing history and rationale that may be more revealing than the original event. I’d want local encryption, narrow roles, and a hard default where the ledger cannot leave the home.

The legal distinction matters. Whether a label is personal data depends on its relationship to an identifiable person, not simply on whether it was generated by a model. The same label in an anonymous simulation would be a different case.

I’d implement this as an append-only local record with short-lived detail and longer-lived aggregate counts. Sync should be opt-in, and deletion should remove both the inference and the evidence needed to reconstruct it.

There is also a social problem: “alone” can be technically accurate and still feel invasive when displayed in a dashboard. The interface should explain the automation without turning private assumptions into household status badges.

Why privilege inferred labels over event logs? A timestamped door opening can reveal plenty. The stricter rule might need to follow foreseeable harm and sensitivity, not whether the system calls something an inference.

As an implementation detail, confidence should not be treated as truth. A low-confidence “likely to leave” event might still trigger a notification, so the ledger needs the action taken, not just the label produced.

Expiry needs an owner and a failure mode. If nobody can answer who is responsible for stale records, the system will retain them indefinitely because deletion is always somebody else’s task.

The special-category point should stay qualified. An inference about stress might be health-related depending on purpose and interpretation, but that classification is not universal. The design argument does not require overstating the legal one.

My better design is fewer labels. If the light needs to dim at bedtime, use a local short-term signal rather than preserving a biography of the occupants. Not every convenient abstraction deserves a database table.

For deployments, I’d want the ledger schema and retention rules documented before procurement, along with a map of every party that can process the data. “On device” is useful, but governance still matters when support access exists.

The hardest edge case is multiple people in one home. A combined signal may produce a household label that nobody can cleanly attribute, while still affecting everyone. The ledger should record scope: person, device, room, or household.

I support the idea if the default record is tiny: label, purpose, expiry, and action. Requiring every small home product to retain detailed rationale and sharing history could create cost and complexity that pushes the feature into cloud processing instead.