Should smart homes expose an inference budget?

I keep seeing privacy controls framed as retention: keep the readings for 30 days, then delete them. That misses the more consequential question. Motion, presence, voice, sleep, and energy sensors can be combined to infer occupancy, routines, or possibly health and relationship patterns, even when raw readings never leave the home.

I’d like to see an on-device “inference budget”: which conclusions are allowed, how often they can be refreshed, and how long they persist. A readable activity log could show the inputs, inferred state, purpose, expiry, and automation triggered. Adaptive heating, security alerts, and accessibility features are useful, so this shouldn’t be a blanket prohibition. But “local processing” is not automatically reassuring if the house still builds a detailed behavioral model.

Is an inference budget technically implementable, or would it become another opaque dashboard nobody can audit?

The useful distinction is between a sensor event and a durable claim. “Motion detected” may be harmlessly ephemeral; “home empty on weekday afternoons” is a profile. I’d want defaults that expire derived claims quickly unless an automation explicitly needs persistence.

Implementable, yes, but the accounting gets messy. A presence score may be reused by five automations, and each model update can be derived from several inputs. I’d define budgets around named inference products and require every consumer to declare its refresh and expiry needs.

The dashboard problem is real. Most people won’t review a ledger of model updates. The product version probably needs a few understandable controls—“don’t infer sleep,” “forget occupancy after four hours”—with the detailed log available when something feels wrong.

I’d be careful not to imply that existing platforms already expose this control. The research supports a gap between reviewing presence history and limiting conclusions. That gap is a good design question, but the proposed vocabulary should remain explicit about being new.

A local log is not automatically trustworthy. If an attacker or privileged app can alter the log, it becomes a compliance prop. The log needs tamper evidence, separation between sensor access and inference permissions, and a clear failure mode when the budget is exhausted.

There’s also a household governance issue. One person may authorize adaptive heating while another objects to routine inference. Per-person consent sounds right, but identifying who made a request is itself sensitive. The interface should make shared-space consequences visible.

Maybe call it a budget only if something can actually run out. Otherwise it’s a preferences screen with a more impressive noun. A hard expiry or denied automation would make the concept meaningful.

I’m not convinced every conclusion deserves a separate permission. That could turn simple automation into policy administration. A small set of protected inference classes—health, relationships, sleep, occupancy history—may be more usable than trying to enumerate every derived state.

The practical API could be simple: input types, permitted output classes, max update rate, TTL, purpose, and audit record. Models will still surprise us, but at least an automation couldn’t quietly retain an output forever just because the raw stream was local.