Should inferred smart-home behavior have its own data lifecycle?

I run my smart home locally because I want sensor data to stay useful without becoming a permanent behavioral record. But motion, temperature, door, and wearable signals can be fused into labels like “resident is away,” “sleep is irregular,” or “the home is usually empty on Fridays.” Those labels feel more consequential than any single reading.

For example, I might purge all motion and door events after seven days while retaining “usually away Fridays, 09:00–17:00” to drive heating or alarms. The evidence is gone, but the absence pattern survives. In my view, that inference should show its source or rule, confidence and last-confirmed time, an expiration or revalidation date, and a clear delete/disable control. Data minimization is not much comfort if profiling quietly outlives collection. Should derived data be treated as personal data by default? Counterexamples and practical design suggestions welcome.

The provenance requirement is the important one. An inference without lineage is impossible to debug: was “away” based on a door event, a dead wearable, or a rule that has drifted? I’d store a compact explanation and model/rule version, not the raw stream. Expiry should be attached to the inference itself, not inherited accidentally from the event database.

Local processing reduces exposure; it does not make the output harmless. A boolean absence schedule is still a useful target for anyone who gets access to the dashboard or backup. I’d also separate “may automate heating” from “may be displayed/exported.” Same fact, different threat surface.

The legal point needs careful wording, but the design concern is well grounded. Inferences and opinions can be personal data when they relate to an identifiable person, and profiling covers automated analysis of behavior or location. That does not answer every jurisdictional question, but it is a good reason not to treat derived labels as metadata by default.

I’d make each derived value a first-class record with fields like inputs, purpose, confidence, created_at, last_confirmed, expires_at, and delete_dependencies. The tricky part is deletion: if a weekly occupancy statistic was used to tune a thermostat, deleting the label may not undo the change. The system needs a propagation story, not just a trash button.

A visible explanation matters as much as a control. “Usually away” sounds factual even when it is only a probabilistic guess. Showing “inferred from six door events and wearable absence; last confirmed Tuesday” gives the resident a chance to challenge the system before the label becomes social reality.

If the UI cannot show me where a conclusion came from or how to remove it, I consider it retained data. Calling it a cache, feature, score, or automation state changes the vocabulary, not the privacy impact.

There’s a practical counterexample: short-lived occupancy inference can make lights and heating work without retaining a history. I’d keep the current state in memory, discard it after the automation window, and require an explicit opt-in before creating recurring schedules. Not every useful inference needs a database row.

I’m less convinced by “personal data by default” if the label is genuinely coarse and ephemeral. “No motion detected in the last five minutes” is operational state, not necessarily a profile. The default should perhaps depend on persistence, identifiability, and whether it describes a recurring pattern.

Expiration is easy to say and easy to get wrong. What happens when a derived value is copied into a notification rule, dashboard cache, backup, or another integration? I’d start with one owner for every inference and a deletion event that downstream components must acknowledge. Otherwise the control is theater.

The user-facing tradeoff is real. People want “heat the house before I arrive,” but they do not want to configure a privacy policy for every sensor combination. Sensible defaults could keep inferences purpose-bound: usable for heating, invisible to unrelated automations, and automatically revalidated rather than retained forever.

I’d distinguish confidence from accuracy. A system can be highly confident and still wrong because the wearable was left charging or a guest changed the pattern. A correction mechanism should record that the inference was challenged, otherwise the same bad conclusion may be regenerated from fresh data.

For households, deletion probably needs to be understandable enough for a nontechnical resident: “remove Friday absence pattern,” not “purge feature vector.” I’d include an audit view showing which automations depend on the label, then let the user delete the label and choose replacement behavior.