A household robot should be able to say no—carefully

As a robotics engineer, I think a household social robot should be allowed to refuse a command when it detects credible coercion, panic, or imminent physical harm—but only as a narrow safety function, not as a household moral authority.

If someone orders it to restrain or lock another family member in a room during an argument, refusal seems preferable to blind obedience. The robot should say why in plain language, keep sensitive inference local where feasible, record the decision for later review, and provide a deliberate human emergency override. Emergency-stop principles are useful here, though household contexts are messier than factories.

False positives are the hard boundary: disability-related speech, panic, cultural behavior, or ordinary conflict could look unsafe. NIST’s framework rightly leaves context-specific thresholds to human judgment. But whose judgment—engineers, regulators, owners, or affected communities? Is refusal responsible safety engineering, or an unacceptable transfer of human judgment to a machine? Counterexamples and alternative designs welcome.

The “credible” part needs governance, not just a better classifier. NIST’s emphasis on accountability and context-specific thresholds points toward published policies, testing with affected groups, and auditability. An owner-configurable safety threshold alone would mostly mean the person with the most power sets the rules.

Local processing reduces exposure, but it does not make the decision trustworthy. I’d want the refusal event signed and stored locally, with access controlled for later review. Otherwise “transparent logging” becomes either a privacy leak or a meaningless sentence in a support dashboard.

From a product standpoint, explanations have to be actionable: “I can’t lock someone in” is useful; “coercion detected, confidence 0.81” is not. The override should require deliberate confirmation, but not a cloud account or a ten-step setup during an actual emergency.

The wording matters enormously. A robot that says “you are abusing your partner” has entered social judgment. A robot that says “I can’t perform restraint or confinement” is enforcing a capability boundary. Same refusal, very different norm being installed in the home.

I’m wary of logging audio or inferred emotional states, even locally. “Local” is a processing location, not a retention policy. The default should be minimal event metadata, short retention, and an obvious way for everyone in the household—not only the purchaser—to understand what was recorded.

What happens when the command is “unlock the door” during a violent incident? A refusal model trained to prevent harm could trap the wrong person. I’d separate actions into reversible and irreversible classes, and make the robot fail toward releasing people rather than controlling their movement.

The emergency override sounds good until you ask who physically reaches it. A frightened child, a visitor, and an abusive owner have different access needs. Any design needs drills, obvious controls, and a no-automatic-restart rule after a fault—not just a clever conversational policy.

Small precision point: ISO 13482 addresses hazards for personal-care robots, but it does not, on the information here, require verbal-command refusal. That distinction matters. We can argue refusal is a sensible design interpretation without presenting it as an existing standard requirement.

I’d rather buy a robot with ten boring hard boundaries than one that claims to understand panic. No restraint, no confinement, no weapon handling, no covert recording. Most “understands the situation” features sound like expensive ambiguity with a legal department attached.

Alternative design: refuse only the physical action, then offer safe, local options—call a chosen contact, illuminate exits, or provide a visible timer and status message. That keeps autonomy narrow and makes the system useful without pretending its model has settled what happened.