A home robot that detects a fall has a surprisingly product-manager-shaped problem: when should it stop waiting and call someone?
Tuya’s new Doova companion robot, unveiled September 4 at IFA 2026, gives that question a concrete answer. If a user appears to have fallen, the robot can move toward them, assess the situation, and wait for a response. After 60 seconds without one, Tuya says Doova starts an emergency workflow and sends family members a two-way live-video alert.
That one-minute decision interests me more than the robot’s multimodal model or its friendly face on a screen.
Physical AI needs an escalation contract
A 60-second timer looks trivial, but writing down what sits on either side turns a small implementation detail into a product decision with human consequences attached. Escalate too quickly and routine floor-level activity, dropped objects, or misunderstood speech can train families to ignore future alerts. Wait too long and the product fails at the moment its safety promise matters most to the person on the floor.
The timer is product; around it sits a sensing chain, a fallback path, and assumptions about connectivity and human response that deserve requirements too.
Doova carries several sensing and communication systems. Its stack combines LiDAR, microphone-based sound localization, vision-based skeletal recognition, mobility, video calling, and autonomous charging, while Tuya also positions the moving device as a smart-home hub rather than a single-purpose emergency appliance.
More sensors can improve context. Every added dependency also gives the decision chain another place to fail when conditions get messy, which is why a PM should trace the escalation from observation through local response and onward to another person.
Which signal started it, and what corroborates that signal? The requirement should say what the device tries locally, how long it waits, who receives the alert when silence continues, and what happens when Wi-Fi, video, or the intended recipient is unavailable at exactly the wrong moment.
That’s still a product flow, even though most of it happens without anybody tapping through a screen.
Measure the quiet failures
Count successful alerts, sure; the more revealing counters include user-canceled alerts, family dismissals, failed calls, events where the robot couldn’t reach the person, and incidents users reported later that the system never detected.
False positives spend trust with every unnecessary interruption. False negatives expose the uncomfortable gap between the product promise and what its sensing system can actually know.
This pattern reaches far beyond eldercare. A leak detector closing a valve and an industrial controller stopping equipment both cross from observation into action, where uncertainty suddenly has physical consequences. Security systems do it too. The interesting requirement isn’t merely “detect X”; it’s the escalation contract around X, including what happens when the detector is unsure.
Model capability doesn’t settle that contract. A benchmark can tell you whether perception improved, but it can’t choose the acceptable delay before an ambiguous observation becomes somebody else’s problem. It certainly can’t decide whether 60 seconds is the right amount of silence before your product calls someone’s daughter.
This is a useful companion to the hardware-lifecycle questions in IoT Smart Modules Turn Component Choice Into Product Strategy. Once software can trigger a physical consequence, the decision path deserves the same design attention as the hardware underneath it.
For a product that acts in the physical world, the timeout may be one of the most consequential lines in the PRD.
Comments
Comments are powered by GitHub Discussions through Giscus.