Home Robot Capability Contracts: Buyer Checklist

The better question is not "Can this robot do the task?" It is: what exactly is the capability contract?

A capability contract is a plain-language version of what robotics deployment teams already need: supported tasks, operating limits, safety boundaries, data assumptions, human handoffs, update rules, and rollback paths. 10Things uses the term directly in its contract-first robotics workflow: define what the robot can and cannot do, validate behavior in simulation, set safety gates, then package telemetry, OTA updates, and rollback into deployment workflows. That framing is useful for home buyers because it turns vague demo language into questions a seller should be able to answer.

For ui44 readers, this is the checklist to use before paying a deposit on a home humanoid, mobile manipulator, companion robot, or modular smart-home robot.

What is a home robot capability contract?

A capability contract is a short, testable description of a robot's job. It should say four things:

1. The task: what the robot is supposed to do.
2. The conditions: where, when, and under what limits it can do it.
3. The safety and privacy rules: what the robot must never do.
4. The recovery path: what happens when autonomy fails.

That sounds obvious, but consumer robot marketing often skips the middle two. "Helps with chores" is not a contract. "Can carry a sealed 1 kg laundry basket from the bedroom to the washer on a mapped route, only while no child or pet is inside a 1 m safety zone, and asks for remote help after two failed grasps" is much closer.

The same idea already exists in safety standards. ISO 13482, the personal-care robot standard, covers mobile servant robots, physical assistant robots, and person carriers. It explicitly focuses on hazards, protective measures, and "information for use" when robots operate around people, domestic animals, and property. Buyers do not need to read the whole standard. They should, however, expect manufacturers to explain intended use and foreseeable limits instead of only showing best-case clips.

Why does this matter more for 2026 home robots?

Because the robots are finally capable enough to be confusing.

A robot vacuum has a narrow contract: clean floors, avoid cliffs, return to dock, empty or wash itself depending on the model. A home humanoid claims a much wider space: picking up objects, opening doors, carrying loads, interacting with people, using natural language, and learning new chores. That wider promise is where buyers get exposed.

The ui44 database shows the spread clearly:

These are not equivalent products. Amazon Astro is a mobile home patrol and Alexa screen with cameras, sensors, Visual ID, and Ring integration. Weave Isaac 0 is a stationary laundry robot with a narrow chore, a 30-90 minute per-load claim in the ui44 record, weekly AI model updates, and remote teleoperation assist when it gets stuck. Hello Robot Stretch 4 is a $29,950 open-source mobile manipulator with a 2.5 kg extended arm payload, 4 kg retracted payload, 8-hour light-load runtime, ROS 2/Python support, self charging, and reference autonomy demos. 1X NEO is a $20,000 home-focused humanoid preorder with soft body design, tactile skin, around 4 hours of battery life, and an official Expert Mode concept for chores it does not know yet.

The capability contract keeps those differences honest.

What should the supported-task section include?

Ask the seller for verbs, objects, rooms, and setup assumptions.

Bad answer: "The robot can help around the house."

Better answer: "It can patrol mapped indoor rooms, check live camera views, recognize known household members, and notify you about unrecognized people. It cannot climb stairs, open doors, or manipulate objects."

That better answer describes Amazon Astro-style value without pretending it is a butler. It is useful precisely because it is bounded.

For manipulators, the task list should be even more specific:

• Can it pick objects from the floor, table, shelf, or washer?
• What shapes and weights are supported?
• Does it handle deformable items like towels and clothes, or only rigid objects?
• Can it recover from a failed grasp without human help?
• Does the task work in any home, or only after a technician maps the space?

This is where narrow robots can beat general robots. Isaac 0's laundry-folding contract is easier to inspect than a broad humanoid chore promise. It has a known task, a known workspace, a mains-powered setup, and a declared human-assist model. That does not make it risk-free. It does make the claim easier to test.

What operating limits should buyers ask for?

A robot capability without limits is just advertising. Ask for a limit sheet.

For a home humanoid or mobile manipulator, the minimum useful fields are:

• Payload: maximum safe load by arm position, not just a heroic number.
• Runtime: active task time, idle time, and charging or battery-swap plan.
• Mobility: thresholds, rugs, stairs, slopes, wet floors, and tight spaces.
• Workspace: minimum lighting, room size, object contrast, and required maps.
• Noise: operating noise for normal motion, fans, and actuation.
• Network: what works offline, what requires cloud inference, and what fails when Wi-Fi drops.

The contrast between robots is important. Stretch 4 publishes concrete physical limits: 160 cm height, 45 cm diameter footprint, 55 cm plus 6 cm wrist reach, 2.5 kg payload with the arm extended, 4 kg retracted, and 46 kg total weight. That is not as exciting as a viral humanoid clip, but it is buyer-useful. Unitree G1 is more humanoid-looking and cheaper at $13,500+, but the ui44 record frames it as a research/development platform with a roughly 2 kg standard arm load, optional dexterous hands, around 2 hours of battery life, and no consumer chore support contract.

A buyer should treat both honestly: Stretch 4 has a clearer manipulator contract; G1 has a lower entry price for developers, not a finished home-service promise.

Which safety gates need to be explicit?

The safety section should describe stop conditions, not only safety language.

Ask for concrete gates:

• What happens if a child, pet, or guest enters the task zone?
• What force, speed, or torque limits apply near people?
• Can the robot detect a trapped cable, fabric snag, finger pinch, or falling object?
• Does it slow down, pause, back away, ask for help, or continue?
• How does the user emergency-stop it without finding an app?
• Does the robot keep operating if a camera is blocked or a depth sensor fails?

Even smaller robots need this discipline. The SwitchBot K20+ Pro is interesting because it makes existing devices mobile instead of promising a general humanoid. Its ui44 record lists a $699 base kit, D-ToF LiDAR, dual laser sensors, Matter support via SwitchBot Hub, and a FusionPlatform that can carry up to 8 kg. The contract question is not "Is 8 kg impressive?" It is "8 kg of what, attached how, moving through which rooms, with which no-go zones, and what happens if it tips, bumps a chair, or carries a camera into a private room?"

That is the kind of safety gate a buyer can actually evaluate.

How should human handoffs be disclosed?

Human help is not a failure. Hidden human help is the problem.

Many near-term home robots will use shared autonomy: the robot handles routine parts, and a human operator steps in when the task gets messy. That can be a good model for early adopters if it is disclosed clearly.

Ask these questions before buying:

• Who can take over: the manufacturer, a contractor, a caregiver, or only you?
• What can the remote helper see, hear, store, and replay?
• Is remote help included in the price, subscription-based, or billed per task?
• Can you approve each session, restrict rooms, or blur private areas?
• How often did handoffs occur in real homes during testing?
• Does the robot learn from handoffs, and can you delete that data?

1X NEO's official NEO page says the robot works autonomously by default, while Expert Mode lets a scheduled 1X Expert guide chores NEO does not know yet. That is exactly the kind of claim that needs a contract. The buyer should not stop at "remote help exists." They should ask when it triggers, what the expert can see, how sessions are authorized, and whether the autonomy improves afterward.

Weave's Isaac 0 raises similar but narrower questions. A remote specialist correcting a laundry-folding failure is less broad than a whole-home humanoid operator, but the privacy contract still matters because clothing, homes, and routines are personal data.

What proof counts before you trust the claim?

A capability contract should include evidence. Not just a polished video.

Useful evidence can include:

• repeat counts, not one-off demos;
• real-home trials, not only lab benches;
• simulation results for edge cases before hardware risk;
• failure-mode examples, not only successes;
• logs showing how often a task needed human help;
• before/after software version notes;
• third-party safety, warranty, or certification documents where relevant.

10Things' workflow is a good mental model here because it separates the promise from the proof loop: hardware understanding, capability contract, simulation evidence, validation gates, and deployment package. A consumer robot seller does not need to expose every internal engineering artifact, but a serious seller should be able to summarize the evidence behind each advertised behavior.

MenteeBot, for example, is exciting on paper: a 175 cm, 70 kg humanoid with a 25 kg carrying claim, 40 degrees of freedom, hot-swappable battery language, NeRF-based mapping, Sim2Real learning, and a 2028 target for commercialization after Mobileye's announced acquisition. That is not a reason to buy today; it is a reason to ask what proof will exist before a buyer lets a full-size robot move heavy objects in a home.

What should OTA, telemetry, and rollback cover?

Home robots will change after purchase. That is good when updates improve navigation, manipulation, voice understanding, and safety. It is risky when an update changes behavior without a clear rollback path.

The contract should answer:

• Are updates automatic, optional, or staged?
• Can safety-critical behavior be updated without explicit approval?
• What telemetry leaves the home, and how long is it retained?
• Can a failed update disable core functions?
• Is there a safe rollback if a new model performs worse?
• How long will the robot receive software and security updates?

This is one reason development-stage robots such as Samsung Ballie need extra skepticism. Ballie has an appealing smart-home contract on paper: Gemini plus Samsung models, SmartThings control, camera-based home monitoring, projection, personalization, and adaptive behavior. But ui44 lists no confirmed price, no confirmed shipping date, and multiple undisclosed hardware specs. A buyer cannot evaluate an OTA policy, privacy boundary, or service life until the product is actually available with terms.

Are capability contracts realistic for consumer buyers?

Yes, if buyers ask for them in plain language.

You do not need a legal document. You need a manufacturer or reseller to state: "This robot is supported for these tasks, in these conditions, with these safety rules, using this data, with this help path, and this update policy."

That standard would make home robot shopping less magical and more useful. It would also reward the companies doing the hard, unglamorous work: publishing limits, admitting handoffs, documenting safety gates, and separating prototypes from deployable systems.

The robots in the ui44 database are getting more interesting fast. 1X NEO, Stretch 4, Isaac 0, SwitchBot K20+ Pro, Amazon Astro, Unitree G1, MenteeBot, and Ballie all point toward different versions of the home robot future. The right buyer question is not which one has the flashiest demo. It is which one has the most honest contract.

Before you buy, ask for the contract. The answer will tell you more than the video.