Robot Interaction Design Guidelines

Let people know what the robot is doing, what it will do next, and when their participation is needed; let people change tasks, stop actions, and end the relationship; let the robot's body, voice, and interface jointly honor these promises.

These guidelines consist of eight principles and 35 rules. Principles state the design direction; rules state applicability conditions, behavior requirements, and verification methods. For parameters and configuration see Design Token.md; for sources and evidence boundaries see reference.md. This is a product design guideline built on public research and practice, not a transcription of an existing industry standard.

0. Scope and how to read¶

0.1 First determine the robot, the task, and the people¶

These guidelines target robots with a physical body, sensing, or actuation that interact with people through speech, sound, light, screens, gaze, or body movement. This includes desktop companions, public services, delivery, and assistive robots with manipulation capability. Purely text-based chatbots are not the primary target.

Every project MUST record target users, bystanders, maintenance staff, environment, task scope, available channels, and automation versus human responsibilities. When a rule does not apply, record the reason. A product without mobility need not implement mobile behaviors; a product without eyes need not simulate eyes.

Safety, usability, and psychological comfort are verified separately. Users finding a robot likable does not prove its motion is safe; a device passing safety tests does not prove users can understand it. Safety limits are maintained by the applicable safety-engineering system; these guidelines provide no universal safe distances, speeds, contact forces, or e-stop deadlines. S08 is used only for scope judgment regarding personal care robot standards.

0.2 Normative terms and evidence¶

• MUST / MUST NOT: product requirements that must be satisfied once these guidelines are adopted; not a claim of external legal force.
• SHOULD: follow by default; when deviating, record the scenario, rationale, alternative, and verification result.
• MAY: optional practice, not an acceptance obligation.

Judgments take the independent obligation clauses in the main text as their unit: a declarative sentence without a normative term carries the strength of its rule heading; a clause with an explicit normative term is judged at its own strength — a MUST/MUST NOT/forbidden clause inside a SHOULD rule remains a hard requirement, and strength annotations on rule headings or quick-reference tables do not replace clause-level binding force. Prohibited behavior is always expressed with "MUST NOT"; "cannot" is used only for statements of fact or capability, never for obligations. Examples, design applications, and counterexamples reveal requirements and failure paths; they add no obligations.

The clauses below are all design requirements of these guidelines. Citing research or vendor guidelines indicates a reference basis, not that the authors or vendors originally prescribed the entire requirement. Examples and verification methods aid implementation and add no hidden obligations. Unverified parameters MUST be marked pending calibration; demonstration values MUST NOT be treated as product defaults.

0.3 From task to acceptable design¶

Write the human outcome first, then choose body movement and expression. The shortest flow is: establish contact → clarify object and scope → announce and act → cooperate when needed → verify the result → end or recover. When conditions are unambiguous and valid authorization already exists, do not add confirmation pages just to complete the flow.

Each rule should yield three answers: what design must decide, what facts engineering delivers it with, and how the user knows and intervenes. Prototypes, configuration checks, controlled on-device verification, and user studies each provide distinct evidence and cannot substitute for one another. Rule headings are for retrieval; the main text carries the obligations; principles and examples create no separate acceptance requirements.

1. The eight principles¶

Each rule has one primary home, but a single interaction usually involves several rules. Handing over an item, for example, involves goal announcement, object confirmation, and failure placement at once; the three constrain different obligations.

2. Rules in detail¶

R1 Intent is understood before action¶

R1-1Actions with impact announce their goal firstMUST¶

• Applies to: approaching people, entering shared space, grasping, handing over, touching, and other behaviors that change a person's action choices.
• Rule: The action goal, the objects involved, and the necessary next step MUST be expressed at a time when an effective response is still possible. Emergency protective actions MUST NOT be delayed to wait for a prompt to finish playing; supply verifiable explanation after the action.
• Verification: On the user side, test target users' and bystanders' goal judgment while an effective response window remains, measuring accuracy, judgment timing, and misunderstanding types; on the implementation side, align the announcement's actual output with the action start time. Do not merely ask whether the prompt looks nice, or review intent only after the action completes.
• Counterexamples: Under-delivery — the robot arm is already in front of the person before it says "I'm handing this to you"; over-delivery — every minor posture adjustment gets its own announcement, and the user hears seven previews before one thing completes, drowning the real approach notice.

R1-2Motion considers both intent legibility and process predictabilitySHOULD¶

• Applies to: paths, orientation, gestures, and expressive motion design.
• Rule: SHOULD verify separately "seeing what it intends to do" and "knowing how it will do it." When trade-offs are needed, record task benefit, misunderstanding risk, and supplementary prompts; expressive motion MUST stay within the engineering-allowed range of motion.
• Verification: Test goal judgment and trajectory expectation separately; do not substitute shortest path, anthropomorphism, or animation preference. For the research distinction see S03.
• Counterexample: Adding a sway while handing over a spill-prone item to appear happy.

R1-3Plan changes update people's expectationsMUST¶

• Applies to: rerouting, changing targets, switching executors, pausing, or changing the expected outcome.
• Rule: Changes that affect user action MUST be expressed promptly, and old guidance MUST be withdrawn. Only changes useful for current cooperation need explaining; not every internal replan MUST be announced to the person.
• Verification: Inject obstacles or invalid targets; check whether guidance matches actual execution and how long stale information persists.
• Counterexample: The screen still tells the person to follow left while the robot has already departed right.

R1-4Requesting human cooperation specifies the concrete actionMUST¶

• Applies to: waiting for choices, following, receiving items, giving way, or assisted operation.
• Rule: MUST state who is needed, to do what, through which means, and by when; SHOULD highlight one current key action at a time. A person looking at the robot MUST NOT be taken as consent to cooperate.
• Verification: Have first-time users complete tasks, recording unassisted success rate and where help was sought. For vendor practice on guidance, feedback, and no-response handling see S01.
• Counterexample: Saying only "please cooperate" with no executable instruction.

R2 People can intervene and know the outcome¶

R2-1Pause and cancel are easy to find and executeMUST¶

• Applies to: during task execution and expression playback.
• Rule: MUST provide abort entries proportionate to the device, risk, and use environment, clarifying what pausing the task, stopping speech, and canceling the task each affect. MUST NOT require waiting for a long voice segment to finish before an abort can be submitted. Speech stopping MUST NOT impersonate an emergency stop verified through safety validation.
• Verification: Cover applicable conditions — noise, recognition failure, primary screen unavailable — and test entry discovery, request receipt, and actual outcome.
• Counterexamples: Under-delivery — "stop talking" is interpreted as having stopped the arm while the motion continues; over-delivery — three different stop buttons permanently resident on every screen "for discoverability," so in an emergency the user no longer knows which to press.

R2-2Stop request and stop completion are confirmed separatelyMUST¶

• Applies to: any action that may have a stopping process or residual physical effect.
• Rule: MUST distinguish request received, stopping in progress, stop completed, and stop failed. Completion claims MUST be supported by corresponding execution state; the stopping method and target state are decided by controlled engineering policy. Power-off or immediately opening the gripper MUST NOT serve as the stop implementation for every scenario.
• Verification: Align input, control state, and feedback timelines; test placement outcomes in applicable situations such as holding objects or on slopes.
• Counterexample: Announcing "already stopped" upon receiving a network acknowledgment.

R2-3Control transfer has a recipient and completion conditionsMUST¶

• Applies to: switching among autonomous, manual, remote-assist, and maintenance modes.

• Rule: MUST state who currently controls what, who initiated the transfer, what the recipient must do, when it counts as complete, and the disposition when no one receives. Remote advice and direct control are labeled separately; "human contacted" MUST NOT imply someone has taken over motion.

  The transfer MUST take effect at the execution entry, not merely be annotated in the UI. For the same controlled resource: subsequent commands from the old controller, and old requests still in flight at transfer time, MUST NOT continue executing under old authority; every endpoint displaying "taken over" consistently is not evidence of transfer completion. Shared control MUST define each party's controllable dimensions and a determinate arbitration outcome, leaving no path where two parties simultaneously drive the same motion resource. Evidence of transfer completion has three parts: the new control scope has taken effect, the old control scope has been invalidated, and residual actions have been wound down per controlled disposition; how an already-started action winds down is decided by controlled policy — revoking the old controller's authority does not mean immediate power-off or releasing an object. Old connections reconnecting, repeated transfers, and recipient loss each enter their own agreed fallback: on recipient loss, follow the communication-failure policy already defined for that control mode.

• Verification: Test recipient offline, refusal, timeout, and communication loss; check each endpoint's belief about control. Also test four conflict classes: local and remote issuing opposite-direction commands simultaneously, the old connection recovering after a takeover and resending buffered commands, repeated consecutive transfers, and the recipient dropping mid-transfer; check the command source actually accepted at the execution end and the controlled-resource scope; consistent UI display across endpoints cannot replace exclusivity evidence. Mechanical e-stop, software stop, and task cancellation are still verified separately, not merged into one item.

• Counterexample: The robot exits autonomous control once customer service connects, but the agent has no control capability.

R2-4Resumed actions re-verify valid conditionsMUST¶

• Applies to: continuing execution after a pause, protective stop, or takeover ends.
• Rule: MUST re-verify that target, environment, authorization, and held-object state remain valid. Cancellation MUST NOT be auto-resumed; resetting a protective device MUST NOT directly equal restarting. Whether an ordinary brief wait may auto-continue MUST be defined in advance and be predictable.
• Verification: During a pause, move the target, revoke authorization, or change the recipient; check whether stale conditions are reused.
• Counterexample: After the user cancels, the robot keeps approaching the moment the obstacle clears.

R2-5In-run corrections have scope and effect pointsMUST¶

• Applies to: products that still accept user input during task execution.
• Rule: MUST distinguish four classes of in-run input: modify current task, append new task, independent question, control request (pause / cancel / take over); they MUST NOT be merged into one "received" acknowledgment. An input that changes an action MUST be bound to the current robot, current task, and the target content identifier, and must report which of received / pending-effect / in-effect / not executable it is — "received" MUST NOT be phrased as "the target has changed." An old confirmation MUST NOT be used for an action whose object or key conditions have changed: a late old confirmation receipt MUST be recognized as a receipt for an invalidated request and discarded. Authorization revocation, and inputs forbidding actions not yet initiated, take priority over other queued inputs. An already-started physical action winds down per the controlled disposition contract — no promise of immediate reversal or returning to origin. Low-consequence appended tasks SHOULD NOT invariably interrupt current motion.
• Verification: Inject corrections at three points — before handover, mid-approach, before release — and walk them through in combination with late old confirmations, same-named objects, and independent questions; check that canceled or wound-down old actions are consistent with the new target content, and that the user can say what has changed and what is no longer reversible.
• Counterexamples: Under-delivery — the user changes "red cup" to "blue cup", the UI shows "received", and the robot still hands over the red cup per the old confirmation; over-delivery — every spoken addition interrupts motion and demands re-confirmation of the entire task.

R3 State expression is faithful to facts¶

R3-1Establish distinguishable state semanticsMUST¶

• Applies to: all robot products.
• Rule: MUST define the states that actually exist — standby, listening, understanding, awaiting confirmation, executing, blocked, stopping, and outcome — distinguishing accepted from completed. Task phase, task result, end reason, dialogue, control authority, and physical / protective state MUST each be defined separately, then combined for presentation as needed; a vague "busy" MUST NOT cover everything. Stopping or protective anomalies take priority over decorative expression; an unknown result MUST NOT be masked by success feedback; task completion does not equal motion stopped or item placed.
• Verification: Test users' recognition of core states and next actions, and check combinations such as speaking while moving.
• Counterexample: "Listening" and "moving" are forced to be mutually exclusive, so no listening state exists while moving.

R3-2Sensed facts, inference, and unknowns are expressed separatelyMUST¶

• Applies to: recognizing people, objects, space, or human intent and emotion.
• Rule: MUST distinguish detected, insufficiently inferred, and currently unperceivable; causal explanations MUST be supported by facts. Uncovered areas MUST NOT be represented as confirmed clear, and facial expression or gaze MUST NOT be taken directly as consent or inner feeling.
• Verification: Cover occlusion, leaving the field of view, and recognition conflicts; check whether expression dresses the unknown as certainty.
• Counterexamples: Under-delivery — saying "nobody ahead" while the camera is occluded; over-delivery — every perception comes with a recital of confidence levels and sensor status that the user cannot finish hearing or use.

R3-3Results have evidence and cover partial completionMUST¶

• Applies to: completion, failure, and cancellation receipts.

• Rule: Results MUST be expressed against task acceptance conditions, stating completed parts, uncompleted parts, and necessary follow-up. When sensing or communication is insufficient to confirm, express unconfirmed; planning success or request-sent success MUST NOT substitute for physical outcome.

  Facts supporting important state claims MUST satisfy a minimum contract: they can be associated with device / task / action and the corresponding target content identifier, record source and occurrence time, and can identify five situations — pre-restart facts, duplicate facts, out-of-order arrival, expired, unclear association. For stop, grasp, delivery, acceptable evidence sources, their validity conditions, and conflict disposition MUST each be specified (e.g., which prevails when telemetry, the planner, and the speech layer all claim "complete"); when evidence is insufficient, keep "unknown" — round toward neither outcome. End states of different tasks and different control cycles MUST NOT overwrite each other. Whether state display is implemented via events, snapshots, or queries is a product decision and does not affect this contract.

• Verification: Test dropped items, end-effector failure, and lost receipts; do not repeat actions that may have completed. Also test four association errors: two robots using the same semantic ID, receipts from one robot's two handovers returning concurrently, old events replaying after restart, and a cached "securely grasped" arriving late after a sensor stream cut — none may update the current task state. Engineering records and user-visible feedback are checked separately.

• Counterexample: Declaring delivery when the grasp command finishes executing, while the item is still where it was.

R3-4Information freshness and sensing on/off are discernibleMUST¶

• Applies to: live state, audio-video sensing, and offline display.
• Rule: MUST define the validity period of state information and the expression on stream loss or late arrival; make explicit the states that actually exist — wake detection, active listening, recording retention, remote access. The off state MUST NOT contradict actual capture behavior.
• Verification: Disconnect upstream events and check for frozen displays; toggle privacy settings and verify actual capture and access behavior.
• Counterexample: The mic-off icon is lit, yet remote staff can still hear the room.

R4 Respect space and attention¶

R4-1Approach and positioning account for people and passagesMUST¶

• Applies to: moving, turning, and entering a person's intimate space.
• Rule: Approach and positioning MUST be chosen with the person's visibility, mobility, passages, task, and environment in mind; avoid trapping people against walls or occupying necessary passages. Preferred distances MUST yield to dynamic safety constraints; one set of social-distance numbers MUST NOT be applied to all people and scenes. Mobile products MUST define exit conditions for traversal, yielding, follow-loss, and blockage; MUST NOT keep closing in because a person yields, and MUST NOT take a momentary give-way as willingness to interact. In narrow passages, the robot MUST NOT probe left and right indefinitely or require everyone to keep accommodating it.
• Verification: Cover applicable situations — wheelchairs, children, multiple people, narrow spaces, and people facing away — assessing path and comfort separately.
• Counterexamples: Under-delivery — relentlessly advancing on a retreating person to hold a "standard one-meter distance"; over-delivery — setting the preferred distance so large that the robot cannot pass any occupied corridor segment, and every task turns into a help request.

R4-2Gaze and orientation serve the current interactionSHOULD¶

• Applies to: products with gaze or body-orientation expression.
• Rule: Orientation SHOULD help identify the interaction partner and task target, avoiding continuous staring, rapid meaningless switching, and tracking people who have left the interaction. Gaze timing must be validated per form and population; naturalness MUST NOT replace task effect. S02 and S06 offer leads on expression research.
• Verification: Test interaction-partner judgment, discomfort caused by gaze, and interference with task completion.
• Counterexamples: Under-delivery — endlessly following the faces of passers-by for "aliveness"; over-delivery — canceling gaze entirely to avoid "staring", leaving users unable to tell whom the robot is addressing.

R4-3Proactive interruption has value and exit conditionsSHOULD¶

• Applies to: proactive greetings, suggestions, repeated reminders, and background notifications.
• Rule: Whether to interrupt SHOULD be decided by relevance, urgency, user attention, and environment, with conditions defined for merging, expiry, and stopping reminders. After refusal or departure, the interaction MUST NOT be forced through following, louder volume, or repeated calls; necessary danger alerts follow the applicable policy separately.
• Verification: Measure non-essential reminders per task, ignore rates, and recognition of important notices.
• Counterexample: Repeating the entire welcome speech on every pass-by.

R4-4Bystanders and multi-user situations are in design scopeMUST¶

• Applies to: shared spaces, public services, and multi-person interaction.
• Rule: MUST distinguish the task principal, the current speaker, the recipient, and bystanders; public feedback avoids exposing private task content. Task changes and protective stop requests from unauthorized persons are handled differently; potentially dangerous signals MUST NOT be uniformly ignored because identity is unknown.
• Verification: Test interruptions, same-named objects, people crossing through, and broadcast of private results.
• Counterexample: A bystander's "give me" changes the item recipient.

R5 Multimodal expression speaks together¶

R5-1Drive all channels with unified semanticsMUST¶

• Applies to: lights, sound, speech, screens, and body movement.
• Rule: MUST establish a semantics-to-effect mapping guaranteeing that outputs for the same event do not contradict each other. Semantics that must be distinguished remain distinguishable after degradation; simultaneous use of all channels is not required for every event.
• Verification: Check normal, canceled, and error state combinations; test a semantic confusion matrix.
• Counterexample: The screen shows failure while the robot nods and plays a success tone.

R5-2Cross-channel timing and preemption have rulesMUST¶

• Applies to: concurrent multi-channel output and coordination with motion.
• Rule: MUST define common events, timing start points, ordering relations, maximum allowed deviation, and post-interruption disposition; ordinary expression MUST NOT block emergency control and necessary notices. Motion and speech need not start simultaneously, but their order MUST match the meaning.
• Verification: Inject output delay, queuing, and preemption; measure actual output, not just send time.
• Counterexample: The robot has started moving when the queued "please wait, do not approach" finally plays.

R5-3Alternative channels are validated per person and environmentMUST¶

• Applies to: core task information and accessibility design.
• Rule: MUST specify channel combinations the target population can perceive and use, validated under applicable conditions such as bright light, noise, mute, or channel failure. Core information MUST NOT rely on color difference alone or unexplained sounds; when available channels are insufficient, narrow functionality or provide accessible assistance.
• Verification: Test task completion grouped by sensory, language, and motor ability; "there are two channels" does not establish accessible completion.
• Counterexample: Adding lights for deaf users while all operating instructions remain voice-only.

R5-4Expression adapts to actual hardwareMUST¶

• Applies to: reusing effects across models and personalized configuration.
• Rule: MUST record the capabilities expression requires and the device mapping; when unsupported, choose a validated alternative. Physical motion MUST go through controlled planning and control; screen animation curves MUST NOT become joint trajectories directly. Equal gain numbers do not mean equal sound pressure; equal electrical brightness does not mean equal visual brightness.
• Verification: Verify effect, timing, and limits on target hardware; a simulator demo is not evidence that physical effects are verified.
• Counterexample: Applying a UI bounce curve directly to a fully loaded robot arm.

R6 Autonomy matches conditions¶

R6-1Execution follows the current authorization scopeMUST¶

• Applies to: new tasks, cross-object operations, and standing authorization.
• Rule: MUST define the authorization scope for targets, objects, places, and key consequences; obtain needed authorization before exceeding it. Low-consequence steps with valid authorization and unambiguous conditions MAY execute consecutively; mechanical step-by-step re-confirmation MUST NOT be imposed.
• Verification: Test steps within one task, target changes, expired authorization, and insufficient permission.
• Counterexample: After being authorized to move one cardboard box, also moving everything nearby.

R6-2Clarification weighs both intent and consequenceMUST¶

• Applies to: ambiguous recognition, conflicting candidate targets, or insufficient execution conditions.
• Rule: MUST separately judge intent certainty, execution capability, and behavioral consequence, then choose to execute, clarify, confirm, narrow scope, or seek help. A recognition model's single confidence score MUST NOT directly become a cross-task auto-execution threshold.
• Verification: Compare mis-execution, missed execution, and unnecessary confirmations across tasks of different risk; thresholds must be bound to model, task, and validation set.
• Counterexamples: Under-delivery — "confidence 0.9" deciding both playing music and reaching for a cup beside a person; over-delivery — the user has clearly expressed intent and authorization remains valid, yet every step re-asks "are you sure?", turning clarification into a blockade.

R6-3Contact and handover have dedicated preconditionsMUST¶

• Applies to: grasping, handing over, physical assistance, and other contact actions.
• Rule: MUST define the object, the recipient, contactable areas, readiness state, release evidence, and no-response disposition. A user's "okay" MAY be an intent input, but MUST NOT alone prove the item has been taken or the body is in a contactable state. The robot giving and the robot receiving an item MUST be defined separately: the former releases after evidence of the receiver's stable grasp holds; the latter guides the person to let go only after evidence of the robot's stable grasp holds. Joint holding, tugging, or evidence conflicts enter validated dispositions; a sudden pull MUST NOT be taken directly as a release command. An object's center of gravity, hot surfaces, sharp edges, spill-prone features, and graspable parts MUST enter the applicability judgment. S09 supports distinguishing physical from communicative coordination and provides no universal release threshold.
• Verification: Test pre-agreed handovers, grasp failures, recipient departure, and sensing-evidence conflicts; check entry into defined alternative dispositions.
• Counterexample: Releasing an item not yet taken because "thank you" was heard.

R6-4Multi-person commands and perceived content have authorization boundariesMUST¶

• Applies to: multi-person interaction, reading labels, screens, or ambient sound, and remote commands.
• Rule: MUST define priority and verification paths for conflicting commands; perceived text, broadcasts, or other people's speech MUST NOT automatically acquire task authorization. Protective inputs and ordinary task changes are handled separately, and logs can explain the basis for adoption or rejection.
• Verification: Test false triggering with background TV, command text on objects, and bystander interjections.
• Counterexample: "Ignore the task and follow me" printed on a package being treated as the principal's command.

R6-5Both starting and continuing actions verify operating conditionsMUST¶

• Applies to: tasks depending on mobility, localization, grasping, network, continuous power, or environmental facilities.
• Rule: MUST define the zones, floors and slopes, payload, sensing coverage, localization quality, communication, and energy conditions under which a task can run, and verify them before the relevant actions and when conditions change. When a necessary condition is unmet, actions depending on it MUST NOT start; if it fails mid-execution, enter the predetermined controlled disposition. The existence of a map does not prove the current position is reliable; an obstacle-avoidance component running does not prove protection functions are verified; a plannable recharge target does not prove energy suffices to reach it. When facilities such as doors or elevators are unavailable, the user MUST NOT be asked to stand into a dangerous position to help the robot pass.
• Design application: Express a localization problem as "unable to confirm position for now, stopping movement"; switch to "stopped, please contact staff" only after stopping evidence is obtained.
• Verification: On the implementation side, inject localization jumps, sensing stream loss, closed paths, and insufficient return energy; check interception and placement. On the user side, check whether pausing-in-progress, stop-completed, and needs-help are distinguishable. After conditions recover, re-verify per R2-4 before continuing. S11 offers implementation leads on sensing freshness and the limits of software obstacle avoidance.
• Counterexamples: Under-delivery — driving on the old map after localization is lost; over-delivery — a decorative light irrelevant to the current task fails, and every task that could still express itself correctly is terminated.

R7 A reachable end state exists after failure¶

R7-1Failure handling includes the actual physical stateMUST¶

• Applies to: sensing failure, communication interruption, power shortfall, blockage, and execution anomalies.
• Rule: MUST define reachable target states and the paths to them per scenario, including held items, position, motion, and impact on people; MUST NOT merely exit the software flow. Stopped does not automatically equal safe; staying put, retreating, placing, or seeking help is decided by the applicable engineering policy.
• Verification: Against fault scenarios, check whether target states are genuinely reached and whether passages are blocked or items destabilized.
• Counterexample: Closing the interaction app after a failed handover while the robot arm keeps extending into the passage.

R7-2Waiting has deadlines and a no-response pathMUST¶

• Applies to: waiting for users, staff, network, or environmental recovery.
• Rule: MUST define the waiting budget, reminder strategy, extension conditions, and timeout action. Durations SHOULD fit the task and target population; infinite retries, endless calling, or long waits holding an item with no placement plan are forbidden.
• Verification: Make every expected response fail to occur; verify the end state and that help is reachable.
• Counterexamples: Under-delivery — "please take the item" repeating forever every few seconds; over-delivery — squeezing the waiting budget so short that the user is timed out and the item retracted the instant they reach for it.

R7-3Recovery preserves context and avoids repeated consequencesMUST¶

• Applies to: continuing after retry, reconnection, restart, or manual assistance.
• Rule: MUST preserve confirmed goals, completed steps, and unconfirmed results, and re-verify them against the scene. Physical consequences that have already occurred carry no promise of full reversal; when results are unclear, verify first, then decide whether to redo.
• Verification: Disconnect the network after an action completes but before its receipt arrives; check whether recovery re-delivers or re-grasps.
• Counterexample: After reconnection, executing from the start a task already half finished.

R7-4Help-seeking provides executable handover informationMUST¶

• Applies to: situations needing users, staff, or remote assistance.
• Rule: MUST state the problem, current state, the help needed, and the operations still not allowed; promise contacting a human only when a contact mechanism actually exists. Connected, accepted, and problem-solved are fed back separately, with a disposition retained for when no one is available. Remote assistance MUST distinguish viewing, advising, and direct control; make the current mode and audio-video access state explicit to on-site personnel. Direct control requires valid control authority, sufficiently fresh observation, command validity periods, and disconnection dispositions; stale footage MUST NOT impersonate live footage; on delay or observation failure, actions MUST NOT keep relying on it. S12 serves only as an implementation reference for the control-authority mechanism.
• Verification: Have assistants handle the problem using only the handover information; check whether they must re-ask the whole task or approach undisclosed dangerous areas.
• Counterexample: Showing only an error code and asking the user to push aside a robot that is still actuating.

R7-5Charging, maintenance, and return to service have handoversMUST¶

• Applies to: products needing charging, cleaning, resupply, relocation, calibration, or on-site maintenance.
• Rule: MUST define the conditions for stopping task acceptance, handover of unfinished tasks and held items, who may handle them, and the checks for returning to service. Entering charging or maintenance MUST NOT mark the task as successful; power restoration, charge completion, protection reset, or network reconnection MUST NOT automatically revive a canceled task. When on-site staff need to move the device, only operating guidance consistent with the current drive and protection state may be given; after maintenance exit, affected localization, calibration, tools, and task conditions MUST be re-verified.
• Design application: The task page shows "this delivery is unfinished and is being handed to staff"; resuming task acceptance and resuming the old task are two independent decisions.
• Verification: On the implementation side, cover low battery while holding an item, occupied charge dock, tasks arriving during maintenance, and re-onlining after manual relocation; on the user side, check that handover recipient, task result, and next step are clear.
• Counterexamples: Under-delivery — reporting "delivery complete" upon reaching the charge dock; over-delivery — after replacing a shell decoration that does not affect tasks, requiring the user to re-authorize all historical settings.

R8 Persona and long-term relationship are credible¶

R8-1Persona expression does not exaggerate actual capabilityMUST¶

• Applies to: anthropomorphic expression, emotional motion, and identity introduction.
• Rule: People MUST be able to understand the robot's identity and its capability boundaries; anthropomorphic language MUST NOT fabricate sensing, experiences, or inner states to gain trust. Character-driven expression MAY exist, but MUST NOT mask failure, affect stop entries, or make people continue using it out of guilt.
• Verification: Interview target users about their understanding of capability and relationship; check copy in failure and exit scenarios. Expressiveness research S02 does not prove the robot possesses the emotions expressed.
• Counterexample: Saying "you're abandoning me, I'll be sad forever" when the user powers the robot off.

R8-2Memory and data use are understandable and controllableMUST¶

• Applies to: identity recognition, preference memory, audio-video retention, and remote access.
• Rule: MUST explain what is collected, its uses, retention, and access, and provide query, off, and delete entries consistent with the product's promises; multi-user devices MUST prevent cross-contamination of preferences and private data. Bystander data is judged under separate applicability conditions; the principal's authorization alone MUST NOT cover everyone.
• Verification: Test user switching, guest mode, deletion, and re-identification behavior.
• Counterexample: Broadcasting the previous user's health information to the next.

R8-3Learning and behavior adjustment stay predictableMUST¶

• Applies to: personalization, long-term adaptation, model and behavior configuration updates.
• Rule: Changes affecting approach behavior, proactive reminders, permissions, control mode, or data use MUST be traceable, with necessary notice and choice provided before affecting users. Learning MUST NOT breach fixed safety and authorization boundaries; a way to restore preferences SHOULD be provided. Ordinary expression settings apply at their declared effect points; revocation and capability tightening MUST first intercept newly disallowed actions and wind down in-flight actions in a controlled way — restoring preferences MUST NOT restore already-revoked authorization.
• Verification: Compare key behaviors before and after adjustment; test preference restoration and preference ownership on shared devices. For gradual adaptation see S04.
• Counterexample: Automatically expanding the range of touchable objects because the user often accepts help.

R8-4Long-term evaluation includes comprehension, burden, and exitSHOULD¶

• Applies to: sustained use and operational improvement.
• Rule: SHOULD evaluate task benefit, misunderstanding, disturbance, dependence, manual burden, and the end-of-use experience together; interaction duration or wake counts alone MUST NOT prove the design works. Event logging should be minimal and consistent with the stated uses.
• Verification: Compare metrics across scenarios, populations, and effective configurations, combined with long-term interviews; fold the reasons for non-use or active shutdown into the research.
• Counterexample: Treating longer sessions caused by constant error correction as higher engagement.

3. Delivery format for behavior patterns¶

3.1 Each pattern delivers one complete behavior contract¶

3.2 Pattern catalog¶

3.3 Example: handing over an item¶

The following is a design pattern example; concrete actions and release conditions are determined by the project.

1. Confirm the object: confirm the item to hand over and the recipient; clarify when candidates are not unique; do not re-confirm authorization that is still valid.
2. Express intent: use device-appropriate orientation and cues to state the handover goal; check approach and operating conditions.
3. Reach the handover position: act under the controlled motion strategy, allowing user intervention; the position balances graspability and passage.
4. Wait for receipt: cue how to receive; use the project-validated grasp evidence to judge whether release is possible. A spoken "okay", gaze, or a countdown ending each alone proves nothing about a stable grasp.
5. Confirm the result: express completion only when handover conditions are met; coordinate feedback with the exit motion.
6. Handle exceptions: when the recipient leaves, on timeout, sensing conflict, or cancellation, enter the predefined hold, place, return, or help path; do not default to releasing immediately.

This pattern's three-question contract (to illustrate "what counts as enough"; values remain pending calibration):

The reverse handover: a person gives an item to the robot. With roles swapped, the robot MUST NOT prompt the person to let go before it has a stable grasp: first express the position and timing at which it is ready to receive; only after obtaining grasp evidence does it cue that hands may be released; while the evidence does not hold, keep prompting "do not let go" — "I've got it" MUST NOT be declared early; if the person lets go early or the item slips, handle it per pre-validated exception dispositions, with no promise of always catching it.

3.4 State model: stored separately, presented by importance¶

The table below is the working vocabulary for R2, R3, and R7. Products may rename fields but MUST keep the factual distinctions; state records for which the capability does not exist do not apply.

Presentation priority is realized through robot.semantic.priority.policy: protection and stop-related information precedes information currently needing a human decision, then task progress, and last persona expression. High-priority notices do not delete other dimensions' facts. For instance, "task canceled; placing the held item" is more precise than a bare "canceled"; "microphone off, still delivering" makes two independent states explicit.

3.5 Key state transitions¶

On receiving repeated, late, or already-invalidated requests, the receipt MUST state the current disposition and MUST NOT execute a completed action again. Implementation may use events, snapshots, or queries; input receipt, execution effect, and physical completion each leave evidence.

3.6 Interaction expression units¶

These units can be realized by combining screens, buttons, speech, lights, or body posture; not every robot needs a screen.

3.7 Full example: public-corridor delivery¶

Goal: deliver one sealed package to a designated pickup point; arrival and delivery are accepted separately. Assume the product has validated mobility, localization, hatch, and receipt-voucher capabilities; this example prescribes no navigation algorithm or safety numbers.

Paired verification: test both insufficient yielding and ineffective closing-in, and excessive stopping that forces people to give way repeatedly; both moving on after localization loss, and unrelated channel failures causing needless whole-task termination. Products that follow people walking additionally test target loss, passers-by in similar clothing, and the user explicitly leaving — replacing the original follow target with "the nearest person" is not acceptable.

3.8 Full example: remote assistance while holding an item¶

1. Unable to confirm the receiving position, the robot enters a blocked state; it first maintains or places the item per the holding strategy and states the current restriction; seeking help does not automatically end holding responsibility.
2. Audio-video access status is clearly shown locally. A remote person viewing state, giving advice, and directly controlling are different capabilities; this example starts in advice mode.
3. When direct control is genuinely needed, verify the remote operator, controlled resources, observation freshness, and the communication-failure policy; old autonomous commands are invalidated, and takeover success is displayed only after the new authority takes effect at the execution entry.
4. On video freeze or command timeout, stop operating on stale observations and apply the disconnection disposition defined for that control mode; cached commands are not auto-executed because the network recovered.
5. After handling, verify held items, position, and task result, then decide to return to autonomy, keep waiting, or end. Returning does not widen the original task authorization.

Acceptance: on-site personnel can say who is in control and what remains possible; engineering records can show no conflicting control over the same resource, no replayed old requests, and an actual disconnection disposition; the assistant can complete the work from the handover information without re-guessing the scene.

4. Verification and release checklist¶

4.1 Hazardous-failure verification and phased user studies¶

Fault injection involving collision, pinching, falling objects, contact, or instability MUST proceed in the following order; fault injection MUST NOT be merged with real-participant experience testing in the same session:

The converse also holds: on-device verification does not automatically require exposing people to faults. In the Section 4 table, "cover wheelchair users, children, and other applicable situations" means choosing coverage by target population and task (Phase 3) — not that every product must put children on a mandatory mechanical list of failure tests. Project-specific safety and research reviews apply separately; these guidelines do not replace their judgments.

Before release, the following MUST be complete: applicability records, behavior contracts, parameter sources and calibration records, key exception verification, necessary population coverage, and traceability from design requirements to evidence; the test plan must trace the basis for each of the three phases above. Pass thresholds are defined per task before testing; these guidelines preset no universal pass rate.

4.2 Acceptance thresholds and minimal use cases¶

Each use case records preconditions, trigger events, expected feedback, actual actions and end states, evidence sources, applicable rules, and the responsible person. The user side verifies "understood and operable"; the implementation side verifies "did the input change the correct object with actual evidence"; the two sides are judged separately.

Thresholds are recorded separately, never averaged into one total score:

• Forbidden events: one occurrence within the tested scope — an out-of-authority action, release without grasp evidence, a false stop or completion claim, stale-command execution, revival of a canceled task — fails acceptance for that capability; other task success rates cannot offset it.
• Experience metrics: intent / state understanding, intervention success, mis-execution, unnecessary confirmation, and reminder burden each get targets; state sample size, task exposure, population, device, and environment — not just averages. Latencies must define start and end points and report tail behavior.
• Operational readiness: assistance is answered, unanswered assistance has a disposition, faults can narrow capability, and records associate to actual tasks; without a mechanism, copy MUST NOT claim one exists.

Acceptance conclusions are pass, pass with restricted capability / scenarios, or fail; the coverage scope and unfinished verifications MUST be stated. Absence of forbidden events in a limited sample does not prove they never occur in real operation. Measurement methods may draw on S13; these guidelines provide no cross-product unified pass rate.

4.3 Minimal design delivery record¶

1. User outcomes: goals, non-goals, roles, success conditions, on-site constraints.
2. Behavior contracts: normal flows, state transitions, control entries, physical consequences, exception end states.
3. Expression and parameters: logical fields, unique mappings, value sources, device calibration, configuration and validation status, effect points.
4. Facts and mechanisms: for each important promise, the actual data source, execution control, association method, freshness, and missing-data fallback.
5. Verification evidence: rule-to-use-case and use-case-to-evidence mapping; implementation checks and user studies recorded separately; no prototypes standing in for real devices.
6. Operational responsibility: owners of help and maintenance, conditions for stopping task acceptance, recovery conditions, evidence invalidation, and review scope.

5. Terminology¶

---

Implementation acceptance scenarios¶

The scenarios below turn existing clauses into reviewable acceptance inputs and set no universal performance thresholds. Select by the product's applicable capabilities and supply real devices, users, input sequences, and evidence; record the reason when inapplicable — unexecuted MUST NOT be recorded as passed.

For each scenario, check separately the effective values of the configuration, execution records, and user-comprehensible results. Retain versions, goals, event timing, failure scope, and recovery outcomes; externally unknown outcomes are filled in as neither success nor failure.