# A Behavior Layer for Robots ## Reusable Interaction Profiles, Human Service References, and Cross-Task Proof **Draft for arXiv submission** **Version:** v1 **Date:** 2026-05-04 ## Abstract Robots are improving quickly at navigation, manipulation, and autonomy, but human-facing behavior remains difficult to package, compare, and deploy. In practice, many behavior differences are still implemented as local scripts, runtime parameters, and property-specific tuning rather than as reusable software. This paper presents a short technical note on Motius Robotics, a behavior layer for robots that treats interaction style as a software object instead of a hidden implementation detail. The core abstraction is an interaction profile that resolves into explicit execution fields such as pause timing, stopping distance, hold duration, and finish softness. These fields are mapped through an adapter into a robot-specific runtime without replacing low-level control or safety. We describe a minimal proof asset on the same humanoid robot across three interactions—object handover, approach-and-stop, and push object—and show that one profile change can produce visible cross-task behavior differences. We then outline a human service reference loop in which human service demonstrations, behavior labels, and robot validation data are used to define and evaluate higher-quality robot behavior. The paper does not claim a complete benchmark or a finished commercial deployment stack. Instead, it argues that robot behavior should become a reusable software layer with structured profiles, scene-specific validation, and eventually a broader behavior ecosystem. ## 1. Introduction Modern robots can already move, navigate, and complete tasks. That does not mean they already know how to behave in front of humans. In many human-facing settings, the central question is not only whether a robot can finish a task, but how that task feels while it is being executed. A robot can arrive at the correct location and still feel abrupt. It can hand over the correct object and still feel rushed. It can stop at the right place and still appear socially awkward. These differences are often visible before any task-level failure occurs. This gap matters because behavior quality is part of the product in human-facing robotics. In hotels, front desks, indoor delivery, reception, and other service-like contexts, users immediately notice differences in stopping distance, pause timing, approach directness, handover rhythm, and exit softness. Yet these differences are still commonly implemented through local tuning hidden inside runtime parameters or scene-specific scripts. As a result, behavior is difficult to compare, difficult to version, and difficult to reuse. This paper argues for a different framing: robot behavior should be treated as a reusable software layer. We present Motius Robotics as a behavior layer for robots. Rather than replacing the controller, planner, or safety stack, Motius Robotics sits above the runtime and packages human-facing interaction differences into reusable interaction profiles. A profile is not a marketing label. It resolves into explicit execution fields that can be mapped into a robot-specific runtime while preserving the low-level control and safety boundary. Our current evidence is deliberately narrow. We focus on a single humanoid robot, a single proof clip, and three visible interaction comparisons: 1. object handover, 2. approach-and-stop, and 3. push object. Within this setup, the paper makes three contributions: 1. It formalizes an interaction profile abstraction for robot behavior that is explicit enough to be mapped, compared, and versioned. 2. It proposes a human service reference loop that combines human demonstrations, behavior labels, and robot validation data to define what good robot behavior should feel like. 3. It documents a minimal cross-task proof in which one profile change is visible across three interactions on the same robot. This is not a claim of general robot intelligence, nor a full benchmark paper. It is a systems-oriented technical note that turns a product thesis into a publishable research framing: behavior can become legible, reusable, and evaluable software. ## 2. Related Work Our work sits at the intersection of social robot navigation, human-robot interaction, behavior modeling, and data/evaluation infrastructure. Recent review work shows that social robot navigation is still far from settled at the level of requirements, datasets, and evaluation, not only planning algorithms. In particular, recent surveys emphasize that suitable evaluation criteria for human-aware behavior remain fragmented across navigation performance, comfort, social appropriateness, and perception by users [1,2]. This motivates work that makes behavior differences more explicit and more measurable. Newer papers also highlight the importance of perceived appropriateness as a first-class evaluation target. PARSNiP, for example, introduces a dataset and benchmark focused on perceived appropriateness in social robot navigation and explicitly includes human emotional state and attention in the problem formulation [3]. This supports our claim that robot behavior quality is not fully captured by task success alone. Related HRI work also shows that small behavior changes can alter how robots are perceived in shared space. For example, robot gaze and related social cues affect social presence and the quality of human interpretation of robot behavior, with scenario-dependent effects [4]. This is consistent with our approach of modeling behavior as scene-sensitive, rather than globally fixed. Our framing also intersects with learning from human references and human preference evaluation. Rather than directly imitating full human body motion, our proposed loop focuses on transferable service primitives—how to approach, how to stop, how long to wait, how to hand over, and how to leave. This is closer to a structured behavior layer than to a full end-to-end imitation system. The closest class of work to ours is therefore not pure motion control, but system designs that bridge human-facing expectations, robot-executable parameters, and validation under shared tasks. Our contribution in this landscape is a narrow but practical abstraction: reusable interaction profiles backed by explicit execution fields and a human reference loop. ## 3. Problem Formulation The problem is not that robots cannot complete tasks. The problem is that the same robot often has to be behaviorally rebuilt for each deployment setting. Today, many human-facing behavior differences are handled through: - one-off scene scripts, - runtime parameters with weak naming, - local QA and tuning, - property-specific deployment adjustments. This creates an implementation gap between robot capability and robot product quality. The hardware can remain constant, the task can remain constant, and yet the desired behavior can change by venue, customer segment, or service standard. We define this as a software packaging problem: > A robot behavior layer should make interaction differences explicit, reusable, and comparable without requiring low-level controller rewrites for each setting. The layer matters most in scenes where behavior is directly legible to people. Examples include: - how the robot approaches a person, - how much distance it keeps before stopping, - how long it pauses before a handover, - how softly it exits after interaction, - whether its movement rhythm feels abrupt or reassuring. These are not merely aesthetic differences. In human-facing robotics, they are product differences. ## 4. Method: Interaction Profiles as a Behavior Layer ### 4.1 Core Abstraction The core abstraction in Motius Robotics is an **interaction profile**. An interaction profile is a reusable behavior object that specifies how the robot should feel during human-facing tasks. Rather than using broad labels alone, a profile resolves into explicit fields that can be mapped to runtime behavior. Typical fields include: - approach speed scale, - stopping distance, - pause duration, - hold duration during handover, - finish softness, - motion smoothing, - end-state control preferences. The profile is therefore not the controller itself. It is a structured interface above the controller. ### 4.2 Two-Layer Execution Boundary We separate the system into: 1. a **behavior layer**, which defines how the robot should behave in a scene, and 2. a **runtime layer**, which still owns low-level execution, safety constraints, planning, and actuation. This boundary matters. It allows behavior to become inspectable and reusable without pretending that high-level profile logic replaces the robot’s full control stack. ### 4.3 Adapter Mapping Different robots and runtimes expose different control surfaces. A shared profile therefore needs an adapter layer that maps robot-agnostic behavior fields into robot-specific runtime values. The adapter handles: - normalization of units and timing, - scaling relative to the robot platform, - mapping into runtime-specific fields, - safety-aware fallback behavior. This gives a path from one shared profile language to multiple robot runtimes, even when the underlying hardware differs. ### 4.4 Human Service References The system is not intended to rely only on robot clips. We propose a second layer of inputs: **human service references**. These references do not attempt to capture full human embodiment as a direct imitation target. Instead, they provide scene-specific examples of transferable service primitives such as: - approach style, - waiting behavior, - handover rhythm, - corridor etiquette, - exit timing. The idea is to define what good robot behavior should feel like by grounding it in references that humans already recognize as professional, calm, or appropriate. ### 4.5 Validation Loop A behavior layer becomes useful only if it can be validated. We therefore propose a loop with three inputs: 1. human service reference clips, 2. behavior labels and preferences, and 3. robot execution proof clips. This allows evaluation not only of task completion, but also of whether one profile is perceived as more natural, more professional, or more service-appropriate than another. ## 5. Proof Setup ### 5.1 Asset Our current proof is a raw validation asset recorded on the same humanoid robot. The reviewed source video has the following properties: - duration: 54.1 seconds, - frame rate: 30 fps, - orientation: vertical, - resolution: 720 x 1280. The current asset is not a polished benchmark. It is a feasibility proof. ### 5.2 Tasks The clip contains three visible interaction comparisons: 1. **Object handover** The robot approaches a user and hands over an object. 2. **Approach-and-stop** The robot walks toward the user and stops in front of them. 3. **Push object** The robot interacts with a wheeled object or platform. These interactions span both navigation-related and object-interaction-related behavior. This is important because it reduces the chance that a profile difference is only a one-task artifact. ### 5.3 Profile Comparison The clip is organized around an A/B comparison between two behavior profiles, currently referred to as **Standard** and **Gentle**. At a high level: - **Standard** is more neutral, direct, and efficient. - **Gentle** is warmer, softer, and more patient. At the execution level, the intended difference is reflected in fields such as: - shorter versus longer pause, - tighter versus wider spacing, - quicker versus softer completion, - more direct versus more gradual approach. ## 6. Observations Our current claim is intentionally narrow: **one profile change is visibly legible across three interactions on the same robot.** ### 6.1 Object Handover In object handover, the visible difference is not only whether the robot reaches the correct location, but how the handover unfolds. The Gentle variant appears to hold longer and exit more softly, while the Standard variant appears more direct and operational. ### 6.2 Approach-and-Stop In approach-and-stop, the legible difference appears before any object exchange. The Gentle variant shows a calmer arrival with more space, while the Standard variant closes more directly. ### 6.3 Push Object In push object, the visible difference is expressed through movement rhythm, smoothness, and finish behavior, which suggests that the profile abstraction is not limited to one specific interaction type. ### 6.4 What This Proof Does and Does Not Show The proof supports the following claim: - one behavior profile change can create visible differences across multiple interactions on the same robot. The proof does **not** yet establish: - cross-robot transfer, - statistically significant human preference results, - production deployment performance across multiple properties, - a complete behavior benchmark. This boundary is important. The contribution at this stage is clarity of abstraction and visibility of cross-task behavior differences, not a claim of completed generalization. ## 7. Discussion ### 7.1 Why This Matters If robot behavior remains hidden in local scripts and property-specific tuning, it will be difficult to scale, compare, or distribute. A behavior layer makes this work more software-like: - profiles can be named, - behavior can be versioned, - differences can be compared, - deployment logic can be standardized. That is valuable whether the downstream setting is hospitality, delivery, reception, or other human-facing interaction domains. ### 7.2 Why Human References Matter Human-facing behavior should not be defined only by what is technically executable. It should also be informed by what people already recognize as appropriate. Human service references provide a way to define better behavior targets without requiring direct one-to-one imitation of full human embodiment. ### 7.3 Why the Current Scope Is Still Publishable Although the current proof is small, it is enough for a technical note because it makes a narrow systems claim: - behavior can be abstracted into reusable profiles, - those profiles can resolve into explicit fields, - one profile change is visible across three interactions on the same robot, - a human reference and validation loop can be defined around this abstraction. This is a credible early systems contribution even before a full benchmark or large-scale deployment dataset exists. ## 8. Limitations and Future Work This work has several clear limitations. First, the current proof is qualitative and based on a single robot clip. Second, we do not yet report a full human preference study with statistically significant results. Third, the current adapter abstraction has not yet been evaluated across multiple robot platforms. Fourth, the human service reference loop is proposed here as a system design and product-research direction, not yet as a completed dataset release. Future work will therefore focus on: 1. a controlled human preference evaluation, 2. structured service reference collection, 3. multi-robot adapter experiments, 4. profile versioning and deployment workflows, 5. scene-specific evaluation metrics for behavior quality. ## 9. Conclusion We presented a short technical note on a behavior layer for robots. The key idea is simple: behavior should become reusable software rather than a hidden collection of local tuning decisions. Motius Robotics implements this idea through interaction profiles that resolve into explicit execution fields, adapters that map those fields into robot-specific runtimes, and a proposed validation loop built around human references, labels, and robot proof clips. Our current evidence is intentionally modest, but sufficient for a narrow claim: on the same humanoid robot, a single profile change can create visible differences across handover, approach-and-stop, and push-object interactions. We believe this is enough to justify a stronger research direction: making robot behavior legible, reusable, and eventually deployable as a software layer. ## References [1] Jarosław Karwowski, Wojciech Szynkiewicz, and Ewa Niewiadomska-Szynkiewicz. *Bridging Requirements, Planning, and Evaluation: A Review of Social Robot Navigation*. Sensors, 24(9):2794, 2024. [2] Rashid Alyassi, Cesar Cadena, Robert Riener, and Diego Paez-Granados. *Social Robot Navigation: A Review and Benchmarking of Learning-Based Methods*. Frontiers in Robotics and AI, 2025. [3] Yunzhong Zhou, Jered Vroon, Zoltán Rusák, and Gerd Kortuem. *PARSNiP: A Novel Dataset for Better Perceived Appropriateness Detection in Robot Social Navigation with Emotional and Attentional Features*. International Journal of Social Robotics, 17(10):2245-2257, 2025. [4] Kerry He, Wesley P. Chan, Akansel Cosgun, Albin Joy, and Elizabeth A. Croft. *Robot Gaze During Autonomous Navigation and Its Effect on Social Presence*. International Journal of Social Robotics, 16(5):879-897, 2024.