Household structure and routines change
Aliases: household change · life events and configuration
What it is
A smart environment's configuration is a snapshot of the household as it was when configured — who lives here, whose schedule is what, how each room is used. Households are fluid: a child is born, an elderly parent moves in, someone switches to night shifts, the study becomes a nursery. These changes silently hollow out the configuration's premises: devices keep working, rules keep firing — but they now answer to a past way of living.
This is the entry point of the long-term evolution problem. It does not say the system breaks; it says something more fundamental: the correspondence between system and environment breaks — and it breaks without errors, because every component is healthy.
Why it happens
Configurations expire because they encode a set of assumptions about life: "only one person sleeps in this bedroom", "nobody is home in the afternoon", "guests rarely come". Life events rewrite those assumptions through a channel that never passes through the system:
- The set of occupants changes: a newborn (nocturnal activity patterns upended), an elderly parent at home during the day (temperature sensitivity), a roommate leaving (every sensing condition for that room changes).
- Schedules change: new jobs, night shifts, children starting school — "the home is empty at night" fails, and the energy-saving automations built on it start doing the wrong things.
- Room purposes change: study to bedroom, living room to gym — the sensor hasn't moved, but the semantics it monitors have swapped.
The key failure mode is semantic drift: hardware and rules run exactly as before, but what they refer to has changed. The motion sensor still fires on "someone in the living room"; what "someone in the living room" means has shifted from "back from work" to "the elderly parent's daytime wanderings". No mechanism in the system can notice this — semantics live only in the user's head, and life does not notify the system.
Studying it
- Long in-the-wild studies: Mennicken and Huang's long-term study of real households documented months of residents continually "hacking" their own systems — rearranging spaces, repurposing devices, patching configurations — showing that the household-system relation is ongoing negotiation, not one-shot installation.
- The domestication tradition: domestication theory from household sociology and communication studies describes how technology is appropriated, given meaning, and reshaped by household rhythms; its vocabulary applies directly — a technology's "meaning" is set by the household's moral economy and routines, and when the rhythms change, the meaning does too. Configuration expiry is the sociological restatement.
- Life-event tracking: longitudinal panel studies treat life events (moves, employment changes, household composition changes) as independent variables, tracking subsequent configuration-editing behaviour and usage interruptions — measuring the lag from "event" to "system mismatch" and the repair rate.
One methodological caution: household change is low-frequency; cross-sectional surveys almost never catch it. Designs must span months to years, and must record both sides — system (configuration, usage) and life (events); with only one side, no correspondence can be established.
Where it stops holding
- Not all change is slow. Moving house, hospitalisation, quarantine rewrite every assumption within days — design must accommodate slow drift and abrupt switchover alike.
- Not every change touches the configuration. Internal shifts of household roles and relationships (who manages money, who does chores) leave the configuration alone but may upset control — the territory of shared-space multi-user problems, distinct from configuration expiry here.
- Change can be induced by the system itself. Automation alters routines (earlier bedtimes) which then invalidate the configuration — system-life co-shaping is another entry; here only life-side-first changes count.
Applying it
- Make the configuration's assumptions explicit: "empty-home hours" as a visible parameter rather than logic buried in rules, so that when life changes, users know where to go.
- Be restrained with seasonal or periodic review nudges — prompt re-examination only when usage-pattern shifts are detected, not by calendar harassment.
- Let key assumptions (occupant count, schedule blocks) be maintained per member rather than one household-wide copy — slowing the expiry rate of "one configuration represents everyone".
- How to check: run an "assumption audit" in the home — list the life assumptions the system currently relies on, have the user check each as "still true", and track how the share of falsified items grows with years of residence; that growth slope is the direct measure of configuration expiry rate.