Technology
Privacy by architecture, not by policy.
A privacy promise is only as good as the system behind it. Ours doesn't rest on a setting you have to trust us to leave switched off — the design simply never produces a stored image to misuse.
What the system actually sees
The image becomes a stick figure. Then it's gone.
A camera in the room captures a frame. On the device, that frame is turned into a stick figure — a set of body points — and the original image is discarded immediately. The stick figure is all the rest of the system ever works with.
Because the conversion happens on the device and the image never leaves it, there is no recording to store, no stream to intercept, and no cloud copy to secure. Privacy isn't a setting you enable or a promise in a contract — it's a consequence of how the system is built.
How detection works
What happens between the camera and a text message.
-
Capture, on a device in the room
A Raspberry Pi 5 with a Raspberry Pi Camera Module 3 (the NoIR variant, chosen so a dim bedroom at night is still workable) reads the camera feed. All processing happens here. There is no separate server doing the work.
-
Pose estimation, then the frame is gone
MediaPipe estimates body position from each frame and outputs a set of pose landmarks — the stick figure. The frame itself is held only in memory for that instant and is never written to disk or sent anywhere.
-
A first model screens for a fall
An on-device classifier looks at how the pose is moving and flags a possible fall. On its own, this stage is intentionally not the thing that alerts anyone.
-
A second stage confirms the person is down
A separate verification stage checks that the person is actually on the ground before the system treats it as real. Two stages, screening then confirmation, are how ordinary movement is kept from becoming an alarm.
-
Only a confirmed event leaves the room
If — and only if — the fall is confirmed, an SMS is sent to caregivers, after a short verification delay. The alert is the single thing that ever crosses the boundary of the device.
Here is that sequence, drawn from the stick figure the device actually produces. Timings compressed.
- Check one — screen. The motion looks like a fall.
- Check two — verify. The person really is on the ground.
- Short delay, on purpose. Compressed in this demo. It exists to cut false alarms.
Images stored during this event: 0 · Images sent: 0
Where the data goes
Three pieces of data. Only one ever leaves.
- The camera frame
- Lives in memory for an instant, never written to disk, never transmitted.
- The pose landmarks (stick figure)
- The working data — the only representation the system reasons about.
- A confirmed-fall event
- The one thing that leaves the device, as an SMS to caregivers.
Because the frame is never persisted, there is no archive to breach, no feed to log into, and nothing to hand over. That is what we mean by privacy by architecture.
At the edge
It runs in the room, not in a data center.
Everything above happens on a small computer in the room — the Raspberry Pi — not on a server somewhere else. The system works offline and doesn't depend on a cloud service staying online to keep watching. Running at the edge is also what makes the privacy model possible: the data never has anywhere else to go.
The camera is night-capable — the NoIR variant of the Camera Module 3 — so the system keeps working in a dark bedroom, where some of the most serious falls happen.
What we deliberately don't do
The honest edges.
- We don't store or transmit video. There is no footage, anywhere.
- We don't identify people. No facial recognition — the system reads posture and motion, not who you are.
- We don't depend on the cloud for safety. The core detection runs locally and works offline.
- We don't require a wearable. Nothing for a resident to charge, wear, or refuse.
It is a camera, and we don't pretend otherwise — the privacy comes from what the device refuses to keep, not from the absence of a lens. The tools underneath, like MediaPipe, are well-established and openly available; our work is the on-device pipeline and the discipline around when it's allowed to alert.
Performance
How we talk about performance.
Fall detection has a well-documented honesty problem: numbers that look excellent in a lab routinely collapse in real homes and care settings. We take that seriously, and we're not publishing a detection-accuracy figure — the number that matters is the one a real pilot produces, and we haven't run that pilot yet.
The pilot is where we'll measure performance in real conditions — night, clutter, real movement — and we plan to put the system through independent third-party testing rather than rely on our own figures. When we publish results, we'll report the raw numbers and the limitations alongside them. If you're evaluating us, hold us to that.
Have a procurement or technical question? Get in touch and we'll answer plainly.
Evaluate it
Want to look closer?
EMOTE4D is pre-launch, piloting in Manitoba in 2026. If you're evaluating the technology, join the waitlist or write to us and we'll walk you through it.
Want to say more than an email address? Use the full form.