Vynleads Haven: Product and Technical Foundation

Proposed capabilities, control requirements, and evidence for a home robot

Research edition · September 12, 2026 · Development introduction

Abstract

Vynleads Haven is a robot concept intended to take on substantial household and care-related work so older adults can remain at home as their support needs change. Its scope includes people with mobility limitations, care partners, and assisted-living communities. Audience research supports the need for this assistance, and robotics studies demonstrate relevant component capabilities. Neither establishes Haven hardware performance, health outcomes, complete caregiver replacement, or commercial readiness. Household assistance, hands-on care, equipment integration, and clinical decisions require distinct permissions and verification. Haven should be evaluated by wanted tasks completed, resident choice, total human effort, recovery, and service cost.

1. Product mission and basis of validity

Haven is intended to help when reaching, carrying, organizing, preparing, or coordinating assistance becomes difficult. It should adapt as a person's needs change, at home or in assisted living. The intended benefit is more wanted activities completed with less unwanted effort, while the resident remains involved in decisions that affect them.

Taking over a caretaker's task does not transfer responsibility for the whole care relationship. Fetching an item, arranging clothing, clearing a surface, or coordinating a routine may substitute for work another person performs. Clinical judgment, safeguarding, personal relationships, and accountability for a care plan remain distinct responsibilities. Claims about task substitution require evidence of the work Haven actually completes.

National Institute on Aging guidance places aging at home within personal preferences, home adaptations, services, and changing care needs. Haven must fit those existing arrangements. A simpler aid or home modification may already solve a problem; compare it with the robot's proposed combination of mobility, manipulation, accessible controls, and coordination. [12]

Technical validity requires a useful task, feasible hardware, repeatable execution under declared conditions, sustained resident benefit, and an affordable support model. The operating envelope means the permitted objects, loads, routes, surfaces, speeds, and proximity to people. Literature supports parts of this chain; the architecture and requirements below are proposed engineering analysis. Digital models and external studies cannot establish performance for a physical Haven product.

2. Audience needs and the limits of acceptance evidence

Older adults' preferences are selective. A 2014 US study of 21 independently living adults aged 65–93 found stronger interest in robots for chores, object manipulation, and information management than for personal care and leisure. This was stated-preference research, not sustained robot use. A 2025 Hong Kong survey of 385 adults aged at least 65 reported robot preferences for 33 of 48 domestic tasks and human preferences for 13, under a hypothetical assumption of human-level robot performance. Its convenience sample excluded diagnosed cognitive impairment and had no robot experience. These populations cannot establish a clean time trend or a Haven adoption rate. [1] [2]

Interviews in the homes of 11 adults aged 67–94 emphasized physically demanding work, individual boundaries, and tasks people wished to retain. Most participants had relatively mild impairments and nearby family support. The relevant design lesson is to ask which part of a routine the person wants help with. Automation should not remove an activity that provides enjoyment, exercise, identity, or a reason to interact with others simply because the robot can perform it. [3]

The 2026 Emergence co-design study makes the service surrounding the robot especially visible. Its first workshop round involved 20 older people and 10 supporters; the second involved 17 and nine, with overlapping attendance. Participants considered domestic fit, cost, privacy, control, charging, maintenance, and training. These workshop totals must not be presented as unique participants or as deployment evidence. They support requirements for the whole ownership experience rather than a capability-only specification. [4]

A 2025 simulated-home study used Stretch RE2 with 12 adults aged 60–97, including cognitive and mobility impairments, during a short single visit. It identified interest in delivery, retrieval, reminders, and safety-related assistance, while excluding diagnosed dementia and using an all-White sample. A separate in-home case followed one nonspeaking man with quadriplegia and his wife through four participatory design cycles with embedded engineering support. Together these studies show the value of accessible, personalized assistance without establishing unsupported home autonomy or scalable labor savings. [5] [6]

Caregiver studies need similar care. Six professional caregivers in a 2025 simulated-home study reported favorable immediate usability, but researchers controlled features that represented autonomous behavior. Brief exposure also changed attitudes in a 2017 study of 12 older adults. A 13-month study of ten robot-vacuum users showed that adoption evolved with household routines. These different methods support repeated, realistic evaluation; they do not show that a compelling first demonstration guarantees long-term benefit. [7] [8] [9]

3. Full product capability map

The capability map sets out intended functions, not current availability. They should share an understandable interface: a resident should be able to request an outcome without knowing how perception, navigation, and grasping work.

Each capability family must be decomposed into concrete actions with a known user, object, destination, interaction method, and completion condition. Preparing a drink station, for example, may require locating a container, navigating, transporting it without spilling, and placing it within reach. Heating a drink or supporting a person to swallow introduces different hazards and authority. Related tasks therefore need separate release decisions even when the public experience groups them under meals and hydration.

Haven should accommodate partial assistance. Someone may want a garment brought nearby while dressing independently, or help setting out an activity they will complete with family. Store these preferences so they do not have to be repeated, but make them easy to review and change.

Personal care and substantial mobility support remain in scope. Section 4 separates permissions and care responsibilities; section 11 addresses body contact and equipment integration.

4. Care authority, consent, and task substitution

Permission belongs to a person and an action. Resident direction is the default when the person can make the relevant decision. Care partners may arrange agreed routines, assist with setup, or receive specified updates. Establish a legal representative's authority through the appropriate process; a family relationship or billing account does not grant unlimited control of movement, recordings, or personal care.

For people with cognitive support needs, the interface should simplify decisions, repeat information consistently, and accommodate supported decision-making. It must not interpret difficulty speaking as a lack of understanding. A scheduled task should pause for refusal, distress, or a meaningful change in circumstances and refer unresolved conflicts to a responsible person. The robot should not independently decide that a care plan overrides the resident's present response.

The tiers below define proposed product permissions and responsibilities, not legal classifications. Moving into a higher-risk tier requires evidence for the task, appropriate oversight, and an assessed environment. A silent software configuration change cannot grant that permission.

Measure caretaker-task substitution at the task level. A retrieval may save one interruption while leaving other care needs unchanged. To assess total support effort, count setup, monitoring, recovery, and service as well as task time. Also record whether the resident can resume activities they had postponed or abandoned; access may matter more than speed.

5. Operation across homes and assisted living

Private homes need an installation process that identifies approved routes, object locations, placement surfaces, room permissions, pets, visitors, and parking. Settings should reflect the resident's routine rather than requiring the whole household to behave like a laboratory. When a task needs an adaptation, the system should explain it concretely and assess whether the resulting assistance remains worthwhile. A changed floor plan or mobility aid should trigger reassessment of affected tasks.

Greater mobility limitations change the meaning of successful delivery. An object placed on a table can remain unusable if it is behind a wheelchair footrest, beyond seated reach, or on a surface that requires an unsafe lean. Approaches must preserve transfer paths and avoid trapping a person against furniture. Controls should be available from the locations the person actually uses, including bed, chair, and wheelchair, with alternatives for limited speech or hand movement.

Assisted living adds staff assignments and shift changes to the task. A 2022 study with seven caregivers in one senior-living community identified interruptions, resident-specific routines, and communication requirements through observation and co-design. It studied workflow, not robotic labor savings. Haven should support assignment, acknowledgment, shift handoff, reprioritization, room-entry permission, and escalation while preserving resident choice. [13]

Every unresolved request needs a responsible recipient. The system must distinguish an accepted request, an attempt in progress, a resident refusal, a failed task, and one awaiting human attention. An unanswered notification should remain open and follow an agreed escalation policy. A robot should never reassure someone that help is coming solely because a message was sent.

Shared deployment also adds cleaning ownership, fleet charging, corridor traffic, belongings identification, and separation of resident data. Facility administration should not give every employee access to all cameras or personal records. Staff access should expire when roles change. The same core task model can support all settings, but each installation must define who operates, authorizes, cleans, maintains, and responds to the system.

6. Accessible interaction and understandable status

Accessibility must cover the complete interaction: starting a request, understanding the proposal, granting permission, following progress, interrupting, canceling, resuming, and obtaining help. Voice is useful but cannot be mandatory. W3C identifies visual, motor, auditory, and cognitive changes relevant to older web users. Its guidance supports accessible digital alternatives, while physical reach, tactile discrimination, and actuation force require separate testing with the intended population. [10]

The companion interface should target WCAG 2.2 AA, including keyboard access, clear focus, adequate contrast, scalable text, and alternatives to precise dragging. Captions and transcripts should accompany meaningful spoken media. This is a design and verification target, not a conformance claim. WCAG 2.2 is a digital-content standard and does not establish that a physical robot control is safe or reachable. [11]

The task display should distinguish Ready, Listening, Checking, Working, Pause requested, Paused, Needs help, Charging, and Service required. Show privacy status separately. Color can reinforce a label but must not carry its meaning alone. Announce essential transitions without repeatedly interrupting the household or relying on a subtle sound.

Confirmation should name the action and destination: for example, bringing an identified closed bottle to an assessed side table. A general YES key leaves the request unclear, so it is absent from the physical design. Allow corrections before motion. Ask for further confirmation when ambiguity or consequence warrants it, without repeating approval prompts for already authorized substeps.

Explain a limitation in ordinary language, identify the help needed, and offer an approved alternative. Do not conceal teleoperation or show a reassuring state after failure. Test comprehension: after an interruption or help request, can the person tell what Haven is doing and what they need to do next?

7. Embodiment and platform strategy

Haven has one public identity, led by the humanoid H02 design. Its neutral model is approximately 1.51 m high and 0.77 m wide. These dimensions communicate scale; they are not validated ergonomic dimensions, a doorway-access rating, or a manufacturing release. Body, hands, feet, enclosure, and sensor positions must adapt to the selected hardware, service access, and resident environment.

Wheeled embodiments belong in technical comparison, not a second announced product. The original Stretch research demonstrated real-home tasks with a mobile base, lift, and telescoping arm: useful manipulation does not always require legs. Those experiments do not establish performance for Haven or later Stretch versions. Compare embodiments on the same tasks, including reach, swept volume, interventions, energy, recovery, and service effort. [15]

Humanoid research strengthens the longer-term rationale while preserving uncertainty. The August 2026 omega-0 preprint reports 11 household tasks with ten trials per task per method. A March 2026 stair study reports its near-100% safe-stepping measure in simulation, separately from hardware results. Figure's January 2026 Helix 02 sequence is a manufacturer-reported four-minute autonomous dishwasher demonstration. These are different evidence types and none establishes Haven's physical performance. [17] [18] [19]

Current integration candidates should be evaluated by exact version. Stretch 4's supplier documentation describes ROS 2/Python interfaces, an omnidirectional base, charging and a quick-change tool interface. However, its current Terms of Sale restrict it to professional non-residential evaluation and state that FCC authorization is pending, with resale and lease restrictions. This makes permitted laboratory development distinct from an occupied-home deployment pathway. [20] [21]

TIAGo Pro offers another comparison point, with two seven-axis arms, torque sensing, joint brakes, parallel grippers and ROS 2 integration in its published configuration. Its product description alone does not establish US residential suitability. Procurement needs written intended-environment confirmation, current safety documentation, supported integration rights, parts availability and service commitments. No supplier is selected or represented as a Haven partner. [22]

8. System architecture and authority boundaries

The conversation layer interprets a request; a local task manager checks identity, permission, supported skills, objects, destinations, and conditions. The motion system executes within measured physical limits. An engineered protective system must be able to inhibit or interrupt movement independently of conversation and the ordinary application. Two processes on one computer do not establish safety independence. Here, software authority means which component may command or inhibit motion; it does not grant the resident's permission.

The approved task record must identify the resident, task, allowed objects, destinations, and surfaces, interaction method, permission reference, skill version, and expiry. It must also define required sensors, route and proximity conditions, energy and attempt limits, recovery, observable outcomes, and any required human acknowledgment. An unsupported request cannot become a motor behavior because a language model can describe it.

Shared sensors, power, networks, clocks and actuators can create common-mode failures. The hazard analysis must identify which components a protective response depends on and whether a single fault can defeat them together. The actual control frequencies, watchdog intervals and communication budgets must be set from the selected platform's measured behavior. Another company's published control rate cannot serve as a Haven specification.

Natural-language content seen on packaging, screens or retrieved pages is untrusted observation. It must not change household permissions, disable protections, request external communication, or authorize remote control. Similarly, a remote service response may inform planning but cannot override the local operating envelope. The task controller should reject stale or malformed commands and preserve a traceable reason for important decisions.

Completion must come from observations. Reaching a coordinate or sending a command does not establish that the correct object is within reach. The task manager must report the verified outcome, including partial completion, uncertainty, interruption, or recovery.

9. Task contracts and completion evidence

A task contract connects the desired outcome to a bounded action sequence: request, clarify where needed, authorize, check, execute, verify, and finish. Pause, refusal, and controlled recovery are valid outcomes. The approved record defined in section 8 sets the conditions and limits for execution.

Consider a personal-item delivery. Haven identifies the enrolled object and the requested destination, checks that the route and placement surface remain usable, acquires a qualified grasp, transports the item in a stable configuration, verifies placement and confirms that the person can access it. If identification is ambiguous, it asks. If the destination is blocked, it does not improvise a placement on the person's lap. A direct handover is a separately qualified interaction, not a convenient substitute for a failed placement.

A garment or activity setup contract uses the same structure with different retention and snag hazards. The robot may handle a tested hanger, container or prepared garment position. Pulling fabric over a moving body is a separate contact-care skill. For connection requests, the contract names the intended contact and reports the actual state of the attempt. An unanswered call must not be reported as a completed assistance request or an assurance of emergency help.

The HomeRobot challenge reported in 2024 illustrates why integration and recovery matter. Its difficult simulation test challenge reached 10.8% overall success for the strongest entry versus 0.8% for a baseline; the authors emphasized improved error handling and perception-decision integration. These historical results are not a current market score. Their relevant lesson is that a sequence of plausible components can still fail frequently as an end-to-end task. [16]

Set attempt limits for each task. Repeated squeezing, blind searching, or retries after permission is withdrawn can increase risk and annoyance. Keep enough context to explain a failure, but discard expired permission. Recovery must leave the robot, its load, and nearby people in an assessed state and identify who is responsible next.

10. Physical controls, status display and privacy switches

The physical control concept retains a large ordinary PAUSE key and a separate red latching emergency-stop actuator on yellow backing. Task approval remains contextual through an accessible interface. The PAUSE key is not a toggle: repeated presses continue to request interruption. The display should acknowledge receipt immediately, then show Paused only when the controller confirms the appropriate stopped or holding state. A request acknowledgment and a completed protective transition are different events.

Pause requires controlled behavior. A biped may need a bounded stabilization maneuver; a manipulator may need to retain a load. Freezing an animation, opening a gripper, or removing all actuator power does not define a safe response. A holding condition needs a validated energy, thermal and stability budget. If it cannot be maintained, the task requires an assessed fallback such as placing the object on a verified surface or requesting trained assistance.

Continuing requires a separate explicit instruction and fresh checks of permission, nearby people, object state, route and hardware. Canceling withdraws the task objective while permitting only the defined safe recovery. Resetting an emergency-stop actuator must not automatically restart motion; Pilz's ISO 13850 explanation describes intentional reset at the initiating device and a separate voluntary restart. The actual circuit, stopping behavior and diagnostics need platform-specific verification. [25]

C2 retains a 160 by 50 mm PAUSE face, a 54 mm STOP cap, and a 78 mm yellow backing. On the neutral H02 model their centers are approximately 1.05 m and 1.22 m above the modeled floor. These are review dimensions, not certified components or proven accessibility limits. Full-size tests must address seated reach, labels, actuation force, clothing obstruction, accidental contact, and discrimination between ordinary and emergency controls.

The C2 review geometry includes a readable READY status strip and a distinct physical MIC slider shown in the OFF position, while retaining the existing pause and stop geometry. These visible controls express the proposed interface; their electrical and protective functions still require engineering and validation. READY should mean that the robot can accept requests through its enabled interfaces, while MIC OFF remains separately visible and means voice capture is disabled. The intended microphone-mute function should disable the capture path through an engineered hardware mechanism, with trustworthy indication and persistence across restart. The camera shutter controls camera capture separately; closing it does not mute audio. Tasks that depend on a disabled sensor must restrict themselves accordingly.

Emergency stop is distinct from normal standby, shutdown and service isolation. The hardware design must provide a deliberate power or standby control and an approved isolation procedure for maintenance. Shutdown must secure posture and any retained load before energy is removed; startup must establish readiness without replaying prior motion. These functions require selected components and a tested sequence even if they are not shown on the front control panel.

A reachable bedside, handheld or alternative-access interface should provide ordinary pause and task control. Consumer wireless links and voice recognition are not credited as safety-rated emergency-stop channels. Supervised engineering use requires an appropriate operator-stop arrangement with defined channel-loss behavior. Website Play animation and Pause animation buttons control only the illustration; they are not demonstrations of a physical robot's stop response.

11. Manipulation, contact care and assistive equipment

Manipulation should start from an object taxonomy: size, mass, shape, surface friction, fragility, temperature, contents, grasp points and consequences of a drop. A compliant parallel gripper, replaceable pads, graspable containers and a transport tray deserve comparison with five-finger hands. Dexterity should earn its complexity by solving useful tasks reliably. Finger geometry alone does not establish sensing, strength, safe pressure, cleanability or the ability to maintain a grasp during movement.

Every grasp should have a verification method appropriate to the object and sensors. Closing the fingers is not sufficient evidence that the correct object is securely held. Transport should consider load orientation, spills, base stability, collision envelope and a recovery surface. Placement needs a verified receptacle and release confirmation. Handovers introduce timing, intent and contact with a person and should be evaluated separately, including hesitation, unexpected withdrawal and limited hand strength.

Physical dressing is an example of a valuable but distinct care workstream. Hao and colleagues evaluated a force-modulated visual policy with 12 participants across 264 trials using two long-sleeve garments. The study addresses partial observations and moving arms, supporting the plausibility of combining vision and force feedback. It does not validate Haven's arms, garments, population or care setting, and a finite participant study cannot establish universal contact safety. [34]

Contact-care development must address pressure, force, duration, body region, discomfort, involuntary movement, vulnerable skin, garment snagging, and the ability to withdraw. Retrieval results cannot qualify dressing, feeding, or bathing. Clinical or care specialists should shape task selection and supervision, while the person retains an accessible way to refuse or interrupt.

Third-party equipment can provide a more appropriate path for body-weight support than general-purpose robot arms. FDA patient-lift guidance emphasizes trained use, compatible manufacturer-approved lift and sling combinations, inspection and load limits. Any proposed Haven integration with a lift, bed or other aid requires manufacturer-supported interfaces, retained protective interlocks and a complete compatibility assessment. Merely sending commands to a device does not preserve its original safety case. [33]

12. Navigation, access, charging and parking

Navigation must represent more than a floor map. The relevant envelope includes the base or feet, moving arms, held objects, turning path, stopping travel and uncertainty. Home qualification should inspect rugs, cables, low furniture, reflective or transparent surfaces, thresholds, slopes, stairs, pets and mobility aids. Approved routes must remain usable when conditions change. A boundary drawn in an application is not a substitute for appropriate physical protection against a drop-off.

Doors and drawers require their own manipulation contracts. A 2024 study of 20 articulated objects across four campus buildings improved reported performance through object-specific adaptation. That result supports further work, while showing that fixture geometry, forces and practice matter. Haven should identify which fixtures are qualified, which need an approved adaptation and which require human assistance. It must not generalize one successful door demonstration to every home or alter fire and egress arrangements casually. [23]

Nav2's Collision Monitor is an example of a useful software layer that checks sensor data outside normal planning. Its documentation explicitly states that it does not provide hard real-time safety certification. It can complement a protective design, but it cannot transform ordinary cameras, software and motors into a certified emergency-stop system. Unknown localization, stale sensing or insufficient clearance must produce the task's defined controlled response. [24]

Charging and parking are core product functions. Haven needs an assessed dock location that preserves walking and transfer routes, protects connectors and manages cables. The interface should distinguish approaching, docked, charging and charged. Nav2's docking framework separately handles dock detection, docking state and charging confirmation, with timeouts and retries. Those mechanisms are useful implementation examples; their default values are not Haven specifications. [26]

The energy policy should reserve enough capacity for the accepted task and its worst credible recovery. A blocked dock requires bounded attempts, an approved alternate parking state and an assigned assistance request. The robot must not continue searching until it loses power in a doorway. Fleet installations additionally need charging schedules and capacity so that simultaneous low batteries do not remove all assistance. Battery faults or overheating require service behavior, not a routine retry.

13. Physical engineering and numerical limits

A physical release requires mechanical assembly CAD, tolerances, load paths, a controlled bill of materials, wiring and power diagrams, actuator and brake selection, sensor coverage, cable routing, cooling and service access. The concept's porcelain-like finish describes appearance; actual enclosure materials need impact, flame, electrical, thermal, cleaning and repair assessment. Rounded surfaces and broad feet are useful design directions but do not by themselves establish pinch protection or dynamic stability.

Hazards include collision, crushing, trapping, snagging, tip or fall events, dropped objects, electrical faults, heat, batteries, liquid exposure and foreseeable misuse. Protective responses should account for frailty, limited balance, fragile skin, assistive devices and inability to move away quickly. Thresholds taken from healthy industrial workers cannot simply be assumed suitable for older residents. Force alone is insufficient: contact area, pressure, duration and body region change the consequence.

A first-order straight-line screening relation is d_required >= v × T_delay + v² / (2 × a_min) + d_uncertainty. Here v is speed, T_delay includes sensing through brake response, a_min is measured available deceleration for the load and surface, and d_uncertainty covers relevant position and geometry error. The relation assumes approximately constant deceleration and is not a complete biped or moving-person safety model. Articulated sweep, slope, balance recovery and foreseeable motion around the robot require additional analysis.

Static stability can initially examine the center-of-mass projection relative to the support region with a justified margin. Dynamic motion additionally requires contact forces, friction, momentum and recovery analysis. A protective response that removes power may undermine a biped's posture or release a suspended load. The design must select a fault-specific safe state and show how braking, reserve energy, mechanical support and load retention achieve it.

Qualified engineers must establish limits for payload by posture, grip force, speed, stopping distance, clearance, thresholds, floor conditions, noise, temperature, energy reserve, and charging. Measure sensing latency, calibration drift, sensor saturation, and fault behavior on the selected hardware. Simulation and geometry can screen a design; release requires measurements of the physical configuration that will be used.

14. Privacy, cybersecurity and offline continuity

The resident's home and care routines generate sensitive information even when the product does not make medical claims. Maps, preferences, object locations, contacts, task logs, images and audio should have separate purposes, permissions and retention rules. The proposed consumer default is no retained raw audio or video unless the person grants a specific recording purpose. Temporary perception needed for a task does not imply permission for long-term storage, remote viewing or model training.

NIST IR 8259A provides a useful starting baseline: device identification, configuration, data protection, logical interface access control, software update and cybersecurity-state awareness. Haven should translate those capabilities into unique credentials, least-privilege roles, protected communications, authenticated updates and observable security status. A baseline reference is not a certificate and must be supplemented with a threat model for the complete robot, companion interface and service. [27]

NIST's April 2026 IR 8259 Revision 1 addresses the wider product lifecycle, including manufacturer responsibilities and communication about maintenance, support and end of life. Haven should define what continues if a subscription, cloud model or support service ends; how updates are delivered; and how residents export or delete information. Ownership transfer should remove prior credentials and data while preserving necessary service records through an appropriate process. [28]

Remote assistance requires a named or otherwise accountable operator, a specific purpose, time-bounded authority, visible indication and an accessible end-session action. The operator should receive only the information and control necessary for the task. Access must not persist silently after the session or a staff-role change. Facility deployment requires separation among residents, roommates and visitors, with contractual and legal data responsibilities determined for the actual service arrangement.

Internet loss must not disable stopping. A task may continue locally only if its released contract explicitly permits that behavior; otherwise it enters the defined interruption state. Reconnection must not replay stale actions. Privacy switches retain their state across restarts, and permission withdrawal invalidates dependent work. Offline status should explain which functions remain available and how to get help, without assuming the resident can troubleshoot networks or recover an immobilized robot.

15. Learning, simulation and the digital concept

Robot learning and personal-preference adaptation should remain distinct. A resident may change reminder timing, preferred destinations or conversational style without changing the robot's contact limits. New locomotion, grasping or care behavior requires development and release evidence. A robot should not explore novel physical actions around residents because it has received an encouraging response or found an instruction online.

Simulation can help develop perception, planning and control when its models represent the relevant physics and failure modes. Useful variation includes mass distribution, friction, actuator limits, latency, sensing noise, object properties and household geometry. Randomizing many parameters does not establish realism if important hazards are absent. Hardware comparison should test where the simulation is wrong, and evaluation data should not be reused to tune away inconvenient failures while retaining the original performance claim.

Separate training, development and held-out evaluation by meaningful units such as objects, rooms, households and participants. A new camera angle in the same room is not evidence of generalization to an unfamiliar home. Every physical episode should identify autonomous execution, remote guidance, direct teleoperation or human assistance. Outcomes achieved through an operator can be useful, but they must not be counted as unassisted autonomy.

The H02 digital concept provides an articulated form, authored motion and spatial references for interaction discussions. Its existing checker samples 2,405 poses and assesses named transforms, ankle-target consistency, sole references and a modeled threshold. These are numerical geometry checks. They do not calculate real mass, friction, contact pressure, dynamic balance or whole-body safety, and they do not establish behavior between samples. A modeled 75 mm threshold is an illustration rather than a traversability rating.

Label rendered films as concept visualizations. Hardware reports must identify the platform and configuration, firmware and skill versions, conditions, attempts, and interventions. Skill release records must include operating limits, regression results, and rollback instructions; remote configuration must not bypass release review.

16. Verification and human evaluation

Evaluate the intended settings while releasing capabilities progressively. Include prospective residents with varied support needs, care partners, facility staff, and people who decline the concept. Use diaries and interviews to identify repeated requests, deferred tasks, and effective workarounds. Test reach, approach, controls, displays, and obstruction with full-size non-powered mockups before fixing the enclosure design.

Bench and furnished-laboratory trials should characterize sensors, payload envelopes, grasping, stopping, power loss, heat, charging and service access. Introduce planned faults with fixtures or surrogates before exposing people. Then test complete routines across held-out objects, changed layouts and interruptions. Platform terms matter: a device restricted to non-residential evaluation cannot be placed in a home simply because the research objective concerns aging at home.

Participant studies need a documented ethics and regulatory applicability determination, appropriate consent and an independent route to stop participation. HHS guidance describes prospective informed consent where its human-subject rules apply and notes the historical limitations of its older FAQ. The applicable requirements depend on the study and institution. Age alone does not imply incapacity; people with greater support needs should be included through suitable communication, representation and professional oversight rather than represented by unrelated volunteers. [29]

After relevant gates, evaluations should include private homes and assisted living, with only the capabilities authorized for those conditions. Compare the assisted routine with the person's usual method and examine repeated use after novelty fades. Report who participated, declined or withdrew; the support provided; and the actual mode of robot operation. Contact-care functions require separate protocols and cannot inherit permission from a delivery study.

Measure correct accessible completion among all initiated in-scope attempts, while recording refusals and excluded requests separately. Also record unassisted completion, intervention frequency, false completion, incidents, near misses, object drops, recovery, time, downtime and voluntary reuse. Total human effort includes setup, instruction, supervision, intervention and cleanup, with resident and caregiver effort reported separately. Passive waiting and subjective burden also matter.

Use confidence intervals and the correct unit of analysis. For zero events in n independent trials, a one-sided 95% binomial upper bound is p_upper = 1 − 0.05^(1/n), approximately 3/n. Zero events in 300 independent trials still permits an event probability near 1%; repeated household trials may be correlated. This illustrates uncertainty, not a Haven result or an acceptable harm threshold. Serious incidents or unexplained protective failures require investigation before the affected evaluation resumes.

17. Service design and economic validity

Installation must assign responsibility for route assessment, dock placement, object enrollment, accessible controls, and training. Residents and care partners need to know who responds when Haven cannot recover. Maintenance must cover gripper pads, fasteners, sensors, exposed seams, approved cleaning, protected battery handling, and a service mode that inhibits ordinary tasks.

Shared care settings need a visible cleaning state and an accountable cleaning owner. CDC guidance calls for setting-specific protocols, trained responsibility for shared equipment and electronics, and compatibility with device materials and instructions. Facility infection-prevention staff should assess the actual use. A material described as washable or a soft outer cover does not establish an adequate cleaning process for every care task. [14]

Haven's proposed advantage would come from choosing useful care tasks, checking permission before execution, offering accessible controls, recovering reliably, and fitting existing routines. A library of tested skills and records of how to install, maintain, and recover the robot could become valuable assets. No proprietary advantage or market leadership is established. Compare hardware suppliers, home adaptations, communication tools, and conventional care as both complements and alternatives.

Estimate cost per useful completed task as (hardware and financing allocation + maintenance + support and supervision + compute and connectivity + insurance and logistics) / useful completed tasks. Disclose development expenditure and deployment capital separately. Count remote operation and on-site intervention, and distinguish both from autonomous execution.

Stress-test the model against low utilization, long training, frequent recovery, short service intervals, unavailable replacement parts and travel for repairs. Measure whether a resident gains wanted activities and whether care partners recover meaningful time. A robot can perform a task successfully while increasing total burden. Product decisions should use measured service effort and voluntary use before projecting labor substitution or savings.

Purchase price, unit cost, margin, revenue, funding requirement, and shipping date depend on a selected configuration, supplier terms, costed operations, and measured use. This paper assigns none of those values.

18. Intended use and regulatory boundaries

Regulatory treatment follows actual functions, intended use, claims and jurisdiction. Calling a system a wellness companion does not determine its classification or remove mechanical hazards. The intended-use statement should be reviewed together with the hardware, software, instructions, demonstrations and care workflows. Household convenience, physical assistance, clinical monitoring and integration with medical equipment may require different analyses within one broader product program.

ISO's catalog currently lists ISO 13482:2014 as the published personal-care robot safety standard, confirmed in 2020 and expected to be replaced by ISO/FDIS 13482. Its scope includes mobile servant and physical assistant robots while excluding medical devices. ISO 13850:2015 remains the published emergency-stop standard, with a review closing on March 5, 2026. The full applicable editions and related test methods should be obtained for design work; public catalog entries do not constitute a conformity assessment. [30] [31]

FDA's January 6, 2026 general-wellness guidance supersedes the 2019 version and addresses low-risk products and certain software functions. Both intended use and technological risk matter. It is not blanket authorization for a moving robot, disease-related claims, or patient-transfer functions. A disclaimer cannot undo contradictory promotional claims or unsafe behavior. Each proposed care function should receive an appropriate determination before it is offered. [32]

The release team should map applicable consumer-product, electrical, battery, radio, cybersecurity, privacy, accessibility and research requirements to the intended market and setting. Supplier component certifications do not automatically cover the integrated robot. Assistive-equipment interfaces and facility data arrangements need separate review. No completed certification, regulatory clearance or Haven physical safety determination is represented by this paper.

Public materials should clearly identify concept visualization and distinguish external research from Haven results. Statements about fewer falls, delayed institutional care, health improvement, caregiver replacement or financial savings require directly relevant evidence. The mission of helping people remain at home can be stated as a development objective without claiming that the outcome has been demonstrated.

This paper contains forward-looking statements about proposed capabilities, integration, specifications, services, economics and availability. Outcomes depend on engineering, testing, funding, supplier arrangements and applicable requirements and may change. Haven is in early-stage development and remains a work in progress. This paper presents the proposed product and technical foundation; a finished robot is not offered for purchase.

19. Release decisions

Each release decision needs a responsible owner, permitted operating conditions, assessed hazards, verification results, and support arrangements. Engineering release requires assembly and electrical documentation, selected components, measured limits, and reproducible tests. Use in occupied settings additionally requires resident suitability, consent, platform permission for that setting, and reliable human follow-up.

References

Sources are current to September 12, 2026 where access dates are given. Published studies, manufacturer specifications and demonstrations, official guidance, and proposed Haven requirements are distinguished throughout. Standards references use public scope and status information, not a full conformity review. Digital dimensions and pose checks describe the authored H02 concept and are not hardware performance results. All Haven architecture, capability tiers, evaluation plans and economic models are proposed unless expressly identified otherwise. No Haven hardware, participant-benefit, certification or financial results are presented.

1. Domestic Robots for Older Adults: Attitudes, Preferences, and Potential — International Journal of Social Robotics; original research indexed by NIH PubMed. 2014-04-01.
2. Human Versus Robot Assistance: Older Adults’ Preferences for Assistance on Domestic Tasks — SAGE Open Aging. 2025-07-30.
3. Older Adults’ Task Preferences for Robot Assistance in the Home — Johns Hopkins University authors; arXiv manuscript. 2023-02-24.
4. Assistive Robotics for Healthy Aging: A Foundational Phenomenological Co-Design Exercise — Journal of Medical Internet Research. 2026-01-28.
5. Robotic support for older adults with cognitive and mobility impairments — Frontiers in Robotics and AI. 2025-04-07.
6. Advancing the design of trustworthy robots for older adults in home environments: A participatory design approach — Proceedings of the Human Factors and Ergonomics Society Annual Meeting. 2023.
7. Integrating Assistive Robots into Professional Caregivers’ Workflow in Aging Healthcare — Proceedings of the Human Factors and Ergonomics Society Annual Meeting. 2025.
8. Older Users’ Acceptance of an Assistive Robot: Attitudinal Changes Following Brief Exposure — Gerontechnology; original research indexed by NIH PubMed. 2017-03-29.
9. The domestication of robotic vacuum cleaners among seniors — Gerontechnology. 2014.
10. Older Users and Web Accessibility: Meeting the Needs of Ageing Web Users — W3C Web Accessibility Initiative. 2025-11-20.
11. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C. W3C Recommendation, December 12, 2024; accessed September 12, 2026.
12. Aging in Place: Growing Older at Home — NIH National Institute on Aging. Revision date not independently confirmed; accessed 2026-09-12.
13. Designing for Caregiving: Integrating Robotic Assistance in Senior Living Communities — ACM Designing Interactive Systems; author manuscript on arXiv. 2022-06; manuscript 2022-05-18.
14. Considerations for Reducing Risk: Surfaces in Healthcare Facilities — US Centers for Disease Control and Prevention. April 15, 2024; accessed September 12, 2026.
15. The Design of Stretch: A Compact, Lightweight Mobile Manipulator for Indoor Human Environments — Charles C. Kemp; Aaron Edsinger; Henry M. Clever; Blaine Matulevich. 2022. original research; ICRA 2022.
16. Towards Open-World Mobile Manipulation in Homes: Lessons from the NeurIPS 2023 HomeRobot Open Vocabulary Mobile Manipulation Challenge — Sriram Yenamandra et al.. 2024-07-09. original challenge report.
17. omega-0: A Latent Predictive World Action Model for Concurrent Humanoid Loco-Manipulation — Zhe Li et al.. 2026-08-09. preprint; original real-robot research.
18. Omnidirectional Humanoid Locomotion on Stairs via Unsafe Stepping Penalty and Sparse LiDAR Elevation Mapping — Yuzhi Jiang; Yujun Liang; Junhao Li; Han Ding; Lijun Zhu. 2026-03-09. preprint; original research.
19. Introducing Helix 02: Full-Body Autonomy — Figure. 2026-01-27. manufacturer demonstration.
20. Stretch 4 Mobile Manipulator Data Sheet, Revision 5 — Hello Robot. 2026-05. manufacturer specification.
21. Terms & Conditions of Sale (Stretch 4) — Hello Robot Inc.. Accessed September 12, 2026. manufacturer contractual terms.
22. TIAGo Pro product and technical specifications — PAL Robotics. Accessed September 12, 2026. manufacturer specification.
23. Adaptive Mobile Manipulation for Articulated Objects in the Open World — Haoyu Xiong; Russell Mendonca; Kenneth Shaw; Deepak Pathak. 2024. original research.
24. Collision Monitor Node — Nav2 maintainers. Accessed September 12, 2026. official software documentation.
25. When the emergency stop is operated on a machine, does it have to be acknowledged on each individual machine? — Pilz. Accessed September 12, 2026. safety-manufacturer standards explanation.
26. Docking Server and Using Docking Server — Nav2 maintainers. Accessed September 12, 2026. official software documentation.
27. NIST IR 8259A: IoT Device Cybersecurity Capability Core Baseline — Michael Fagan; Katerina Megas; Karen Scarfone; Matthew Smith; NIST. 2020-05. government technical guidance.
28. NIST IR 8259 Revision 1: Foundational Cybersecurity Activities for IoT Product Manufacturers — NIST. 2026-04. government technical guidance; final revision.
29. Informed Consent FAQs — HHS Office for Human Research Protections. Accessed September 12, 2026. government research-ethics guidance.
30. ISO 13482:2014 — Robots and robotic devices — Safety requirements for personal care robots — ISO. 2014-02. official standard catalog entry; public scope and status only, full standard not reviewed.
31. ISO 13850:2015 — Safety of machinery — Emergency stop function — Principles for design — ISO. 2015-11. official standard catalog entry; public scope and status only, full standard not reviewed.
32. General Wellness: Policy for Low Risk Devices — US Food and Drug Administration. 2026-01-06. government nonbinding regulatory guidance.
33. Patient Lifts — US Food and Drug Administration. Accessed September 12, 2026. government medical-device safety guidance.
34. Force-Modulated Visual Policy for Robot-Assisted Dressing with Arm Motions — Alexis Yihong Hao, Yufei Wang, Navin Sriram Ravie, Bharath Hegde, David Held and Zackory Erickson. CoRL 2025; preprint September 16, 2025. Original research.

Return to the Vynleads Haven concept page.