The system needs periodic review, not one-shot configuration
Aliases: configuration maintenance · ongoing upkeep
What it is
Since households change and rules drift, configure once, run forever is an illusion: a smart environment needs tending like a garden — reviewing whether rules still fit life, clearing zombie configuration, re-checking the life assumptions the system relies on. Maintenance is continuing labour, not a one-time investment at installation.
The inverse of this conclusion is exactly the mainstream marketing narrative: "set it up once and it learns and adapts, no management needed". Learning systems do chase life — but only the parts sensors can see. Schedule semantics, room purposes, household conventions: these life-side changes still need a person to translate them into configuration. Review cannot be abolished by "intelligence"; it can only be arranged — the question shifts from "whether to maintain" to "who bears the labour, when, and at what cost".
Why it happens
Why can't review be left to spontaneous user initiative? Because it is missing on both the motivation side and the signal side:
Motivation: review is purely preventive labour — its benefit (avoiding future unreasonable behaviour) is invisible, while its cost (sitting down and going through rules) is immediate. With no discomfort pending, review ranks last on the to-do list forever; by the time discomfort arrives it is firefighting, not review.
Signal: drift is symptomless (rules fire normally, no errors), and the system generates no natural "time to review" reminder. The lights work as always; nothing hints that "three rules' premises have expired".
With both ends missing, review is systematically postponed and drift accumulates — until some sufficiently glaring misbehaviour puts it on the agenda, by which point the user faces not a configuration to check but a pile of rules nobody can account for.
For review to happen, the system must supply the signal and compress the cost: package the "time to look" reminder with the "what to look at" list, and drive the cost of a single review down to minutes. That is the designable part — the necessity of maintenance is given by life; its bearability is given by the product.
Studying it
- Maintenance records in long in-the-wild studies: smart-home research observes residents' continuous tinkering, and notes that the labour falls disproportionately on one member (usually the original installer) — maintenance doesn't happen not only because it is hard, but because nobody owns it.
- Reminder-timing experiments: compare review completion rates and annoyance under different triggers — calendar-based (quarterly) versus event-based (usage-pattern shifts, repeated reverts, season switches). Event-based triggers typically achieve higher completion at lower annoyance, because they carry the reason "why now".
- Cost-manipulation experiments: present the same review tasks under different organisations (rule-by-rule vs. grouped by scene; bare list vs. with firing history), measuring completion time and drop-off — decomposing "review is expensive" down to information organisation.
One methodological caution: review completion is not the final criterion — whether the reviewed configuration then fits life better (revert rate down, misbehaviour reduced) is; optimising only "user clicked confirm" produces ritual review where nothing changes.
Where it stops holding
- This entry covers review driven by life change; drift from mutual adaptation between automation and user behaviour is a different review object — different source, different question ("has life changed?" vs. "has it learned badly?") — and the two should not be merged into one reminder.
- Review has an interruption budget. Each review requisitions attention; the frequency ceiling is set by annoyance, not completeness. Better to leave blind spots than to irritate — a review feature switched off protects nothing.
- Not every configuration needs the same review cadence. Safety and protection rules need verification (does it still work?) rather than review (is it still appropriate?) — different mechanisms that drag each other down when merged into one flow.
Applying it
- Fire the review entry on events: only after usage-pattern shifts, repeated rule reverts, season switches, or device moves — each with a one-line "why now"; calendar reminders only as fallback, off by default.
- Package each review by scene: "the 4 rules linked to Coming Home, each with the last 30 days of firings and reverts" — one screen, three keys per rule (keep / disable / delete) — driving cost down to minutes.
- Leave an audit trail: what was reviewed and changed this time becomes the baseline shown next time — reviews accumulate instead of starting from zero.
- How to check: track two numbers together — review completion and the change in revert rate over the following 60 days; high completion with unchanged revert rate means the review is theatre. Also watch the household distribution of the labour: if it always lands on the same person (and is already a complaint source), a sharing mechanism is due.