The problem
Living alone with dementia turns ordinary things into risks. A stove left on. A front door opened at 3am. A dose taken twice, because the first one was forgotten.
The default answer is cameras, and the literature is consistent about where that breaks: surveillance is the point at which both families and the people being monitored stop accepting the technology, and bathrooms and bedrooms are exactly where the risk sits. So the privacy constraint was accepted first and the problem became inference under it.
A single reading is incomplete. Presence in a bathroom is not safety. A vacant bed at night may be a two-minute trip rather than wandering. An opened medication box records an interaction, not a dose. The system has to act on far less than a camera would give it, distinguish the ambiguous case from the dangerous one, and be wrong rarely enough that a carer keeps reading its alerts at all.
What I did
- The care rulebook
- The finite-state model that turns readings into a judgement. Care states run SAFE → MONITORING → WARNING → CRITICAL, with separate UNKNOWN and DEGRADED states so sensor uncertainty is represented rather than silently read as safety, and every transition carries its own entry condition, timer and reset. Safety scenarios and daily-support routines are deliberately two rule families, with emergencies holding priority over reminders — one undifferentiated alert queue is what produces the alarm fatigue that makes carers stop looking.
- The sensor model
- What each sensor can and cannot establish alone, and how readings compose into something worth acting on. Devices emit only normalised events — motion or idle, present or absent, open or closed, occupied or vacant, on or off — against one message shape carrying sender, zone, device type, message type, payload and timestamp. No scenario logic lives in a sensor, so changing a rule never means touching the device layer, and a zone's condition is derived from several sensors rather than trusted from one.
- Research and literature review
- The evidence base the design is argued from: roughly forty peer-reviewed sources across ambient assisted living, passive sensing, activity-of-daily-living recognition, the ethics of sensor surveillance in dementia care, and caregiver burden — resolved into a stated gap the project addresses. The no-camera stance and the separation of emergencies from routine prompts are conclusions drawn from that reading, not preferences.
How it works
On screen
The full research poster. The methodology strip along the top is the argument in order: generate residents, let them act, sense ambiently, interpret through the rulebook, then compare where rules hold and where they break.
Decisions
Cameras, or ambient sensors?
ChoseAmbient sensors only
Instead ofCameras in the home
The acceptance research points the same way repeatedly: visual surveillance is where adoption fails, for the family and for the monitored person, and the highest-risk rooms are exactly the ones where a camera is least tolerable. Taking the constraint as fixed rather than as a preference is what forced the rest of the design — the system has to reach a decision on far less information than a camera would hand it.
How much can a single reading prove?
ChoseEvery reading is evidence, never proof
Instead ofTreating a sensor as ground truth
An open door is not proof someone left. An opened pill box is not proof a dose was swallowed. Acting on one reading produces false alarms, and false alarms are what make a carer stop reading alerts.
What happens when two alerts collide?
ChoseEmergencies override routine reminders
Instead ofOne queue, in order
A carer pinged all day stops noticing the one that matters. Priority is part of the safety design, not a notification setting.
Should the system explain itself?
ChoseEvery alarm carries the rule chain that produced it
Instead ofA confidence score
A score is unfalsifiable in the field: a carer handed 0.82 can neither verify nor dispute it. A state that names the scenario, the evidence behind it, the timer that elapsed, the action taken and the condition that will clear it can be checked, corrected and argued with — which is what keeps it in use, and what makes a wrong threshold a fixable bug rather than an unexplained false alarm.
Where it got to
- The architecture
- Layered, and deliberately local: sensors into a local hub, a gateway holding routing, device registry, logging and dashboard state, then a finite-state safety controller and a routine engine running beside it, with actuators, the caregiver dashboard and a remote bridge downstream. Every simulated component maps onto a real deployable equivalent — a Zigbee-class coordinator, a Home Assistant-style local gateway, an ESP32-class controller — so the model is a deployment plan rather than only a diagram.
- The simulation
- The home is built in Unreal Engine, so sensor events can be injected and cross-zone scenarios replayed identically instead of staged by hand. An earlier network-simulator build was abandoned when it could not share state across rooms through a single controller; moving to a full simulation is what made cross-zone reasoning possible at all. Events are written as structured logs, so behaviour can be analysed after the fact rather than watched live.
- Where it goes next
- The rulebook's timers are baseline values that need personalising per home, and you cannot deploy into fifty real dementia homes to learn whether the rules generalise. So the next build generates a synthetic population of LLM-driven residents who act out their own daily routines inside the same simulation, with one rulebook watching all of them, to find where rules false-alarm and where they miss — plus a sandbox where anyone can author a care rule and run it against the whole population. The method is borrowed from published work on generative agents producing personalised activity data; the contribution is turning it on care-rule validation.