A Hierarchical Architecture for Embodied Intelligence Systems: Enabling Embodied Intelligence Through Layered Decoupling and Unified Standards

1. Introduction

Artificial intelligence has advanced rapidly over the past decade. In particular, progress in deep learning [1] has produced remarkable results in digital domains such as computer vision and natural-language processing. Conventional AI operating in digital space, however, lacks the ability to interact directly with the physical world. Against this backdrop, embodied intelligence [2] has attracted growing attention and is becoming an important frontier in the next stage of AI development.

As its technical potential has become apparent, embodied intelligence has drawn substantial industrial investment. Start-ups, research institutes, consumer-electronics companies, and automobile manufacturers with established supply chains have all entered the field. Yet the expansion of the industry has also exposed several systemic risks.

Embodied intelligence is inherently interdisciplinary and systemically complex. Its technology stack spans mechanical engineering, electromechanical system design, electronics and embedded systems, automatic control, computer science, and artificial-intelligence algorithms. This breadth makes it difficult for any single organization to address the entire stack independently, raises the technical barrier to entry, and constrains large-scale industrial development.

Research and commercialization in embodied intelligence nevertheless remain dominated by closed vertical integration. Many organizations build an entire monolithic stack, from mechanical design and manufacturing through environmental perception and low-level control to high-level task planning. Some systems separate cognitive decision-making from low-level control—often described as a “brain–cerebellum” division—and some involve limited collaboration across organizations. Even so, their system boundaries and communication interfaces are commonly tied to proprietary protocols for a particular hardware platform. They therefore fall short of genuine, cross-platform system-level decoupling. Such closed development repeatedly recreates common low-level technologies, increases total development cost, fragments the ecosystem, and raises the barrier to cross-domain deployment and large-scale adoption (Figure 1). The consequences are visible at four levels:

• Hardware. Robot embodiments are highly heterogeneous and weakly standardized. Developers commonly adopt custom hardware topologies and proprietary communication protocols for physical specifications and key electromechanical components, including rotary and linear actuators and multi-fingered dexterous hands. Without common low-level standards, actuators, sensors, and controllers from different vendors cannot readily be exchanged as modules or made interoperable at the system level. This isolation limits component reuse at scale and creates substantial engineering barriers when software and control systems must migrate to new embodiments.
• Data. Collecting high-quality physical-interaction data still depends heavily on human teleoperation, making large continuous-trajectory datasets costly in both time and money. Non-standardized embodiments also cause data collected by different organizations to differ substantially in distribution, which further limits reuse. For complex, long-horizon tasks in open and unstructured environments, exhaustively collecting end-to-end trajectories remains difficult to justify technically or economically.
• Models. Existing embodied-control algorithms are often deeply tied to a particular hardware platform, which makes direct transfer of model parameters and motion policies across heterogeneous robots difficult. Pure end-to-end models can struggle with physical commonsense reasoning and adaptive task decomposition on out-of-distribution or long-horizon tasks. Changes to motor characteristics or manipulator geometry may also degrade or invalidate a large pretrained model. Training and maintaining a separate foundation model for every hardware topology is therefore expensive and difficult to sustain.
• Industry. Closed, weakly coordinated development leads to substantial overlap in engineering effort and early-stage capital. Teleoperation infrastructure, chassis and gait control, and basic kinematics are repeatedly rebuilt across organizations. In the absence of shared standards and systematic decoupling, these duplicated efforts increase total system cost and reduce the efficiency with which the industry allocates capital and expertise.

Overcoming these limitations requires a shift in emphasis from isolated algorithmic optimization to system-level architectural reconstruction and standardization. The history of computer systems offers a useful structural precedent. Inspired by that history, this paper proposes the Embodied Intelligence System Level Hierarchy (EISLH). We examine how layered decoupling can reduce system complexity and improve cross-platform reuse, with the broader aim of encouraging an open, modular, and extensible system architecture for embodied intelligence.

As an initial feasibility study, we conducted systematic experiments on a high-fidelity simulation platform and implemented a closed-loop process for a bipedal humanoid robot performing complex tasks in open scenes. Part of this preliminary work appeared at the International Conference on Learning Representations 2026 [3].

2. Lessons from the Evolution of Computer Systems

The evolution of computer systems provides an important architectural reference for addressing the technical and industrial challenges of embodied intelligence. The broad generality and cross-platform interoperability of modern computers do not arise from a single, elaborate monolithic design; they rest on an ecosystem of layered abstractions [4].

From physical hardware through operating systems to application software, every level of a computer system performs a distinct role through standardized interfaces. The principal advantage is the decoupling of system complexity: hardware can evolve independently of the software ecosystem, while device drivers conceal differences among physical devices so that application developers need not understand the underlying circuitry. This modular, protocol-driven pattern allows an advance at one level to benefit the broader ecosystem. The history of computing therefore suggests that hierarchy and standardization are important foundations for technology at scale. Robotics has explored related principles through the subsumption architecture, 3T, CLARAty, and 4D/RCS, which respectively emphasize behavioral layering, coordination between planning and execution, reusable autonomy software, and closed-loop control across multiple time scales [5,6,7,8].

To reduce ecosystem fragmentation and support deployment at scale, embodied-intelligence development should gradually move from closed vertical integration toward open, layered decoupling. By clarifying functional boundaries and standardizing each level, the emphasis can shift from building isolated, bespoke robots to cultivating a broadly compatible hardware–software ecosystem.

Such a hierarchy offers four main technical and ecological benefits:

• Managing overall complexity. A highly complex full stack can be divided into modules with clear boundaries and independent responsibilities.
• Decoupling hardware and software. Algorithm researchers can focus on particular cognitive or control components, while hardware vendors improve robot morphology and motion performance without repeatedly rebuilding the full system.
• Improving interpretability and traceability. Explicit, structured intermediate representations make the path from cognitive reasoning to physical action more transparent and easier to debug and assess for safety.
• Supporting specialization. A modular division of labor can reduce low-value duplication and mitigate ecosystem fragmentation.

Robot architectures, middleware, and modular standards have long investigated planning–execution decoupling, component reuse, and interface description [7,9,10]. Even so, there is not yet a widely converged engineering specification for an end-to-end architecture spanning general multimodal models, cross-embodiment semantic action interfaces, and closed-loop physical safety. A transition toward standardized layering is therefore an important path for handling device heterogeneity and deploying embodied systems robustly in the real world.

3. Embodied Intelligence System Level Hierarchy

To address architectural limitations in cross-platform deployment and complex-task execution, we propose the Embodied Intelligence System Level Hierarchy (EISLH). As illustrated in Figure 2, EISLH separates an embodied system into five closely coordinated but clearly bounded functional levels:

• User Command and Physical Environment. As the system input, this level grounds abstract natural-language commands in the robot’s physical environment and defines the initial boundary for human–robot interaction and environmental perception. Like a high-level language in a computer system, it allows users to express intent in natural terms without attending to implementation details.
• Embodied Compiler (EC). This high-level cognitive and logical-planning module decomposes a macroscopic task into atomic actions that respect physical commonsense and temporal constraints. Analogous to a software compiler, the EC translates high-level semantics, such as natural-language intent grounded in a particular environment, into structured machine-action instructions and thereby bridges unstructured intent and discrete robot operations.
• Embodied Instruction Set Architecture (EISA). EISA is the shared intermediate interface of the embodied system. It consists of platform-independent core instructions, a capability-description mechanism, and embodiment- or industry-specific extensions. Core instructions express the goals, constraints, and results of operations such as observation, navigation, grasping, carrying, and stopping, without referring to joint counts, motor parameters, or control methods. Capability descriptions declare which operations, resources, parameter ranges, and safety bounds a robot actually supports. Extensions capture platform-specific morphology, tools, and workflows. EISA provides the EC with a standardized target format and the EAE with a common execution contract, preserving stable core semantics across heterogeneous hardware.
• Embodied Action Executor (EAE). This low-level control and motion-synthesis module converts discrete EISA instructions into continuous trajectories and dynamic control signals for a particular robot. Analogous to microprogramming, the EAE interprets platform-independent operations as embodiment-specific sequences that accommodate the robot’s mechanical and electromechanical structure.
• Embodied Hardware. The mechanical body, actuators, servos, and sensor arrays form the physical substrate that ultimately exchanges matter, energy, and information with the world. Analogous to digital logic and physical hardware in computing, this level realizes commands and control signals as physical interaction.

Together, the five levels form a standardized execution chain from abstract intent to concrete physical operation (Figure 3). The layered architecture addresses fragmentation in cross-platform deployment, data reuse, and industrial coordination in four respects:

• Hardware. By encapsulating low-level control instructions behind a unified abstraction, EISLH hides differences among embodiments, makes core electromechanical components more replaceable, and supports the migration of execution capabilities across platforms.
• Data. EISLH lowers barriers to reusing interaction data. Collection can focus on frequent, basic physical interactions and produce standardized atomic-skill datasets for different embodiments. Modular composition and dynamic orchestration of those subtasks can then cover more complex, long-horizon tasks without depending exclusively on a single enormous end-to-end dataset.
• Models. EISLH separates high-level reasoning from low-level physical execution. A general multimodal model can contribute semantic interpretation, logical planning, and adaptive decomposition in open environments, while the execution module maps standardized instructions to hardware-specific dynamics and control. This division can preserve the broad reasoning abilities of foundation models while reducing their coupling to a particular robot.
• Industry. EISLH can support a transition from closed vertical integration to horizontal specialization and standards-based collaboration. Clear system-level boundaries allow research institutions and companies to concentrate on particular levels, such as hardware, execution middleware, or cognitive reasoning. Modular specialization and open sharing of common infrastructure can reduce duplicated engineering and improve integration across the supply chain.

4. User Command and Physical Environment

User Command and Physical Environment is the top level of EISLH and the initial point of contact between an embodied-intelligence system, human intent, and the physical world. Analogous to a high-level programming language, it allows end users to express broad task intent in natural language and logic without attending to physical execution or control. Its central responsibility is to ground highly abstract, and sometimes semantically incomplete, human instructions in the robot’s perceived three-dimensional environment, thereby establishing the baseline boundary for interaction and perception.

As the front line of human–robot collaboration, this level should support natural interaction through text, speech, and multimodal guidance. It should also authenticate users, check authorization and task legality, and perform an initial screening for ethical risk, rejecting commands that are plainly unlawful, unauthorized, or unethical. This is an input-level filter only: it does not determine whether the robot has the required capability, nor does it provide real-time motion safety. Those responsibilities belong to the EC, EAE, and independent hardware-safety systems.

From the perspective of application ecosystems and commercial deployment, a mature command-and-environment interface is a prerequisite for embodied intelligence at scale. Natural, high-level interaction removes the traditional robotics requirement that specialist engineers write scripts or program waypoints with a teach pendant. By hiding low-level complexity from end users, this level lowers the threshold for adoption and enables embodied agents to enter unstructured workplaces and living environments more naturally, providing an interaction foundation for their evolution toward general-purpose computing platforms.

5. Embodied Compiler

The Embodied Compiler (EC) is the central bridge between high-level intent and low-level physical execution. It combines an abstract or semantically incomplete user command with multimodal observations and the current state of the embodied agent, compiling them into a structured, executable sequence of embodied atomic-action instructions.

For task safety, the EC performs task-level capability matching and constraint checking. Before producing an EISA action graph, it should query the robot’s capability description and verify support for the required opcodes, execution resources, parameter ranges, and safety constraints. If a task exceeds the robot’s capabilities or violates a hard constraint, the EC should reject compilation, revise the plan, or request user confirmation. The EC also writes task-level bounds on velocity, force, workspace, and human–robot separation into EISA execution contracts and safety envelopes. It does not, however, perform high-frequency motion control or real-time collision handling.

Although the EC resembles a software compiler in conventional computing, operation in the physical world is substantially more demanding: compilation and logical decomposition must remain correct in a dynamic environment subject to unforeseen disturbances. Robust deployment requires two principal capabilities:

• Generalization and adaptation in open environments. The EC must avoid dependence on a single predefined scene or set of objects and interpret unfamiliar environments as they evolve.
• Reasoning and planning for complex, long-horizon tasks. Natural commands are often concise and abstract (for example, “the room is messy”), while the corresponding physical operations are numerous. The EC must decompose a global objective into minimal executable subtasks while respecting causal logic and physical laws, and should seek an efficient plan without unnecessary steps.

Both capabilities remain technically challenging. One practical route is to build the EC around mature general-purpose multimodal models such as GPT [11], Claude [12], Gemini [13], and Qwen [14]. Representations learned from large, cross-domain corpora can improve adaptation to open scenes, while the models’ reasoning abilities can help interpret concise goals and decompose long-horizon tasks. PaLM-E further demonstrates that continuous sensor observations, state estimates, and language can be jointly processed for embodied reasoning and sequential robotic manipulation planning, making embodied multimodal language models a natural candidate for implementing parts of the EC [15]. SayCan, Code as Policies, Inner Monologue, and Hi Robot have explored this direction through skill affordances, program generation, feedback-driven planning, and hierarchical VLA policies, respectively [16,17,18,19].

Mainstream general-purpose multimodal models still have limited native access to physical quantities such as three-dimensional position, mass, temperature, and touch. One practical response is to combine deep neural networks with explicit physical solvers (Figure 4). A multimodal model handles language, images, and audio for scene understanding and target recognition. When a task requires exact spatial coordinates, relative distances, contact pressure, temperature, or other physical properties, the system directly invokes sensor observations and calibration parameters, including camera intrinsics, force–torque measurements, and thermal readings. Bypassing implicit neural inference for critical physical quantities both avoids known representation limits and preserves accuracy and real-time response.

Prior work [3] provided an initial demonstration of three-dimensional perception and reasoning with commercial general-purpose models through a “2D-first, 3D-assisted” pattern. The method overlays visual grid anchors on a two-dimensional image, prompts the model to identify the anchor associated with a target object, and then uses the underlying simulation engine to recover exact three-dimensional coordinates. Although the reported evaluation focused on simulation, an analogous pipeline in the physical world could combine camera calibration with depth measurements from sensors such as LiDAR.

Skill-3D [20] further investigates how a large model can select tools for different three-dimensional tasks. It distills successful tool-use trajectories into reusable skills and records failures as corrective experience. For a new scene, the model composes tools for object detection, depth estimation, three-dimensional reconstruction, and related operations to obtain more accurate spatial evidence. The reported results improve three-dimensional reasoning and extend the earlier 2D–3D collaboration pattern toward adaptive tool selection.

6. Embodied Instruction Set Architecture

The Embodied Instruction Set Architecture (EISA) is the shared intermediate representation in EISLH and a principal means of reducing hardware–software coupling. Analogous to a conventional instruction-set architecture, EISA establishes a standardized semantic interface and execution contract between the high-level EC and the low-level EAE. Robot command languages, task-representation standards, and hardware-independent action recipes have addressed related problems [21,22,23]; EISA brings version negotiation, capability description, safety envelopes, and normalized results into the same interface.

Unlike conventional CPU instructions that operate on virtual registers, EISA instructions refer to physical states in the real world. Each instruction is a structured tuple describing a basic operation—such as grasping, navigation, or observation—together with the geometric and physical parameters needed to constrain it, including target entities, three-dimensional coordinates, end-effector poses, and relative displacements.

To support cross-platform reuse and deployment at scale, EISA follows three engineering principles:

• Generality and modular composition. The instruction library should cover common physical interactions and support the composition of basic operations into more complex behavior.
• Hardware decoupling at an appropriate level of abstraction. The interface should conceal low-level electromechanical quantities such as motor voltage and joint torque while exposing calls based on geometric relations and semantic intent.
• Adaptive feedback in dynamic environments. Instruction definitions should include feedback and event-triggered semantics for dealing with disturbances during physical execution.

Manipulators, bipedal and quadrupedal robots, and wheeled platforms differ substantially in morphology and motion capability. EISA therefore does not attempt to encode every hardware detail in one fixed instruction set. Instead, it adopts a layered design of common core instructions, capability descriptions, and embodiment- or industry-specific extensions. Core operations such as observation, navigation, grasping, carrying, and stopping retain consistent goal and result semantics across platforms. Capability descriptions state each robot’s supported motion modes, resource types, parameter ranges, and safety bounds, while extensions capture differences such as gait control, specialized tooling, or application-specific processes. This design complements the module information models of ISO 22166 and the skill conditions and capability reasoning in SkiROS2 [24,25,26]: the former describes composable modules, the latter provides a concrete skill-execution framework, and EISA focuses on the instruction contract between EC and EAE.

EISA versions follow major, minor, and patch numbers, with backward compatibility within a major version. A minor release may add optional fields, opcodes, predicates, or result information; a patch release corrects errors or wording without changing semantics. An incompatible change to an opcode, field, or execution meaning requires a new major version. EC and EAE negotiate supported versions and features through capability descriptions to prevent misinterpretation between implementations.

EISA is expected to evolve in two main directions: broader composable operation semantics and result predicates, and richer representations of physical quantities, tolerances, uncertainty, and evidence. The perception and control precision that a robot can actually achieve belongs in its capability description, not in the EISA version number.

The design may also be discussed through an analogy with reduced- and complex-instruction-set computers (RISC and CISC) [4,27]. The analogy does not imply that robot semantic operations behave like CPU instructions. At the present stage, a compact EISA centered on frequently used atomic operations can constrain engineering cost and reduce the data required for high-quality interaction. Its limited coverage, however, may require unusual actions to be expressed as longer compositions, potentially increasing plan length and reducing motion continuity in complex work.

As data ecosystems and robot hardware mature, EISA should preserve a small, stable common core while supporting richer capabilities and workflows through capability descriptions, action graphs, and namespaces. In short, the core states what is to be achieved, the capability description states what the robot can achieve, and extensions state how a specialized capability is expressed on a particular platform. Backward compatibility is preserved within a major version, and incompatible changes advance the major version. Table 1 presents a minimal example; Appendix A gives the full specification.

7. Embodied Action Executor

The Embodied Action Executor (EAE) is the low-level motion-control center of EISLH. It converts discrete, standardized instructions produced by the EC into continuous, smooth physical motion that satisfies the dynamics of a particular robot and ultimately realizes interaction with the world.

In deployment, the EAE must manage the complexity of low-level physical interaction. It has two principal responsibilities:

• High-dimensional motion synthesis from atomic instructions. The EAE parses standardized EISA instructions and combines them with geometric constraints in the current environment, such as obstacle avoidance, and with the robot’s kinematic and dynamic limits to generate collision-free, physically feasible trajectories in real time.
• Disturbance-resistant, high-frequency actuation and closed-loop control. The latency and computational cost of large models generally make direct high-rate control unsuitable for industrial safety and stability requirements. As an independent low-level controller, the EAE resolves spatial trajectories into servo commands and fuses data from sources such as IMUs and joint encoders in a high-frequency feedback loop. This loop suppresses external disturbances and supports stable, safe execution.

The EAE is the real-time safety authority during motion execution. It continuously monitors collision risk, human–robot distance, velocity, acceleration, force, workspace bounds, and body stability, and may locally replan, slow down, pause, or execute a protective stop. It may not relax hard safety constraints delivered by the EC through EISA. Even after input filtering and capability checks, the actual state observed at execution time remains the basis for the final motion-safety decision.

Two broad algorithmic paths are prominent in current EAE research. The first uses continuous generative architectures such as diffusion models. A structured EISA instruction acts as a condition, and the model produces an action segment or trajectory. Diffusion Policy and related work [3] illustrate representative approaches to action diffusion and embodied-action generation [28].

A neighboring line of research generates human motion primarily for digital humans, games, film, and AR/VR. DeMoGen uses an energy-based diffusion model to decompose motion into interpretable, reusable semantic concepts that can be recombined [29]. EnergyMoGen composes multiple energy terms in latent space to generate motions from multiple semantic concepts [30]. InfiniDreamer uses segment score distillation to extend short-horizon priors into arbitrarily long motion sequences with smooth transitions [31]. ClusterStyle uses global and local prototype clustering to represent within-style diversity [32]. These methods target visually natural, semantically coherent, expressive virtual-human motion rather than direct robot control. Nevertheless, semantic decomposition and recombination, long-sequence stitching, parameterized motion style, and generative priors may inform skill organization, trajectory initialization, and candidate-action generation for bipedal humanoid EAEs. Visual plausibility on a human skeleton is not equivalent to dynamic feasibility on a robot. Transfer to a physical biped still requires retargeting and closed-loop enforcement of contact, center-of-mass and balance stability, joint and torque limits, self-collision, and execution safety. Such models are therefore better treated as internal motion priors or reference-trajectory generators than as unverified sources of servo commands.

The second path uses autoregressive vision–language–action models that serialize visual feedback, proprioceptive state, and task instructions to predict actions. RT-1, RT-2, RT-H, and OpenVLA represent large-scale real-world control, transfer of web knowledge, linguistic action hierarchies, and an open VLA implementation, respectively [33,34,35,36]. Any of these could contribute to an EAE implementation, but an internal action representation is not automatically a cross-platform EISA contract.

Regardless of the data-driven generation method, deployment in the physical world typically combines learned components with inverse kinematics, inverse dynamics, operational-space control, model-predictive control, and servo feedback [37,38,39]. Infrastructure such as ROS 2 can integrate the modules [9]. A neural model may produce action segments, spatial trajectories, or target poses at a higher level, while classical control and safety filters enforce dynamics, collision, and stability constraints in a high-frequency loop [40]. Such a hybrid architecture seeks to combine the generalization of data-driven methods with the explicit constraints of model-based control; the combination alone does not constitute a safety guarantee.

8. Embodied Hardware

Embodied Hardware is the physical foundation of EISLH and the final carrier of matter, energy, and information between an embodied-intelligence system and the real world. Analogous to the physical hardware and logic levels of a computer, it receives low-level servo commands resolved by the EAE, realizes them through the mechanical body and actuators, and returns environmental observations and proprioceptive state through sensor arrays.

This level should include a body-safety supervisor, limit protection, and a hardware emergency-stop circuit independent of higher-level software. These mechanisms have the highest priority in the system and must not depend on successful communication with the EC or EAE. If a drive fault, communication loss, mechanical-limit violation, or another severe hazard is detected, the hardware-safety system should directly cut or restrict power and report the trigger and final state to the EAE.

Under a modular, decoupled architecture, the development of embodied hardware should emphasize three engineering dimensions:

• Standardized electromechanical interfaces and modular configuration. Flexible replacement and reconfiguration require common physical specifications for mechanical topology, such as standardized mounting flanges, and for electrical buses such as industrial EtherCAT and CAN. ISO 9409-1 specifies mechanical interfaces for industrial-robot end effectors, while ISO 22166 supports module reuse through information models for service-robot modules [24,41]. Such componentization provides a basis for assembling, maintaining, and replacing heterogeneous hardware.
• Fidelity and timeliness of heterogeneous sensing. As the system’s contact with an open world, the hardware level should integrate high-frame-rate vision, multi-axis force–torque sensors, flexible tactile arrays, high-accuracy absolute joint encoders, and other complementary sensors. Multimodal observations should be aligned by hardware timestamps and delivered to the EAE and EC with low communication latency.
• Actuator dynamics and physical limits. Interaction performance depends on the limits of actuators such as high-torque-density motors, quasi-direct drives, and artificial muscles. Within constraints imposed by mechanics and thermal dissipation, the hardware should provide sufficient control bandwidth and dynamic response to realize the continuous trajectories produced by the EAE faithfully.

At the ecosystem level, hardware–software decoupling can release specialized innovation in manufacturing. Once shared intermediate instructions and driver protocols are established, robot manufacturers need not duplicate sophisticated high-level cognitive algorithms and can focus engineering resources on materials, precision electromechanical transmission, and biomimetic design. A more specialized horizontal supply chain could then support independent vendors of dexterous hands, nonlinear elastic actuators, and specialized sensing modules. Scale in standardized components may in turn reduce the manufacturing cost and adoption barrier of embodied-intelligence systems.

9. Related Concepts and Work

Research on embodied-intelligence systems has produced several related lines of work on architectural hierarchy, task representation, skill reuse, and cross-embodiment execution. This section reviews classical robot-control architectures, brain–cerebellum divisions, task and skill representations, foundation-model-based hierarchical policies, robot middleware, and execution safety, and then situates EISLH with respect to them.

9.1. Classical Hierarchical Robot Architectures

Hierarchical organization has a long history in robotics. Brooks’s subsumption architecture incrementally added behavioral capabilities and organized fast reactive behaviors and higher-level behaviors as asynchronous control layers [5]. The subsequent 3T architecture divided a system into planning, task-sequencing, and reactive-skill tiers, and evaluated this hybrid hierarchy across several robot types, processors, and operating systems [6]. These studies established an important principle: long-horizon decision making and high-frequency environmental response operate at different time scales and should not be assigned to a single control loop.

CLARAty organized autonomous-robot software into decision and functional layers, emphasizing reusable components across heterogeneous robotic platforms [7]. The 4D/RCS architecture instead used multilevel, multiresolution control nodes to coordinate sensory processing, world modeling, value judgment, and behavior generation over different temporal and spatial scales [8]. Both sought system integration, component reuse, and closed-loop autonomy, and are therefore directly relevant to the concerns addressed by EISLH.

These architectures primarily explain how autonomous software should be organized and how planning, execution, and reactive control should cooperate. EISLH adapts this systems perspective to multimodal foundation models and heterogeneous embodiments: it makes the functional boundaries from user intent to physical execution explicit and defines EISA as a versioned, negotiable, transport-independent semantic contract between EC and EAE. Classical architectures thus provide conceptual foundations for EISLH, while EISA is the interface on which the present work concentrates its standardization effort.

9.2. Embodied Brain–Cerebellum Architectures

Industry and the technical media increasingly use a “brain–cerebellum” analogy to describe a basic division of labor in embodied-intelligence systems [42]. The “brain” generally performs multimodal perception, semantic understanding, task decomposition, reasoning, and decision making. The “cerebellum” converts high-level goals into continuous actions and handles motion coordination, balance, and real-time feedback control, while the physical embodiment performs the resulting actions. In earlier robot-control research, Albus’s Cerebellar Model Articulation Controller (CMAC) applied cerebellum-inspired associative learning to control a multi-degree-of-freedom manipulator [43]. The modern phrase “embodied brain–cerebellum,” however, usually denotes the broader functional separation between cognitive models and motion-execution modules.

Several systems explicitly adopt this analogy or a closely related neuroanatomical decomposition. AeroAgent treats a large multimodal-model agent as a “brain” and a flight controller as a “cerebellum,” connecting the two to ROS through ROSchain for task planning and stable UAV execution [44]. RoboOS comprises RoboBrain for global perception and high-level decision making, a modular Cerebellum Skill Library, and real-time shared memory for multirobot coordination [45]. A hierarchical learning controller has also been organized into cortex-, cerebellum-, and spinal-cord-inspired pathways and evaluated on a hexapod robot [46]. NeuroVLA similarly uses a three-level organization of cortical planning, adaptive cerebellar stabilization, and spinal-like fast execution, focusing on the time-scale mismatch among semantic reasoning, high-frequency feedback, and rapid reflexes [47]. The precise meaning and boundaries of the levels differ across these UAV, mobile-manipulation, and legged-robot systems.

A related body of work describes the hierarchy as System 2–System 1 or as a high-level VLM coupled to a low-level policy. GR00T N1 uses a vision–language module to interpret the environment and instruction, followed by a diffusion Transformer that generates continuous actions; the two components are trained jointly [48]. Figure Helix uses a lower-frequency System 2 to produce semantic representations and a higher-frequency System 1 for continuous upper-body control; Helix 02 adds a System 0 for balance, contact, and whole-body coordination [49,50]. DIAL connects a VLM-based System 2 to a System 1 action decoder through a differentiable latent intent [51]. WholeBodyVLA uses a VLM to produce latent action and manipulation outputs and executes stable locomotion with a reinforcement-learning policy for mobile manipulation [52]. These systems exhibit a comparable separation between cognition and action execution, but their interlayer signals are commonly internal latent variables, action conditions, or motion commands.

Several Chinese industry projects provide additional engineering examples. The “Huisi Kaiwu” platform released by the Beijing Humanoid Robot Innovation Center combines an embodied “brain” for task planning with a data-driven embodied “cerebellum” for skill execution, closing the loop through skill invocation, state feedback, and error handling [53]. AgiBot’s EI-Brain further separates a cloud “superbrain,” brain, cerebellum, and brain stem, corresponding respectively to task-, skill-, instruction-, and servo-level functions [54]. Galbot positions AstraBrain-WBC 0.5 as a “cerebellum” model for real-time whole-body humanoid control [55]; the associated Humanoid-GPT study learns whole-body motion tracking with a causal Transformer and examines scaling motion data and model capacity [56]. These projects illustrate practical brain–cerebellum divisions, although public descriptions differ in interface openness, cross-embodiment reuse, and evaluation scope.

In this paper, “brain–cerebellum” is used only as a concise functional analogy for cognitive decision making and motion execution. Roughly, EC overlaps with some “brain” functions, EAE with some “cerebellum” functions, and the embodied-hardware layer with the physical body. EISA lies between EC and EAE and explicitly represents operational semantics, resource binding, execution constraints, asynchronous state, and results. Unlike skill calls, latent representations, or motion commands internal to the systems above, EISA is intended as a versioned, negotiable, transport-independent cross-layer interface. This is a functional comparison; it does not imply that existing brain–cerebellum systems use the same number of layers, terminology, or implementation mechanisms as EISLH.

9.3. Task Representations, Command Languages, and Skill-Execution Frameworks

EISA is most directly related to prior robot task representations and command languages. The Canonical Robot Command Language (CRCL) represents robot tasks, control commands, and status information in a platform-independent manner [21]. IEEE 1872.1-2024 specifies an ontology of robot task knowledge, task hierarchies, and their relationships to support knowledge representation, reasoning, and exchange [22]. From a modular-systems perspective, the ISO 22166 series defines common information models, interfaces, services, states, and safety-related information for service-robot modules and software modules [10,24,25]. These standards address command exchange, task knowledge, and module descriptions, respectively, and provide useful foundations for EISA’s semantic vocabulary, capability descriptions, and modular interoperability.

RoboEarth action recipes describe tasks independently of particular hardware, declare the objects, environment knowledge, and robot capabilities required for execution, and can be converted into executable plans on a target platform [23]. SkiROS2 integrates a knowledge base, automatic task planning, behavior-tree execution, and skill libraries, using preconditions, hold conditions, and postconditions to describe skills [26]. Behavior trees organize complex tasks through hierarchical composition, state feedback, and reactive switching [57], whereas PDDLStream combines symbolic task planning with continuous constraint solving for kinematics, collision, and visibility [58]. These mechanisms correspond to different parts of EISA’s capability discovery, execution contracts, action graphs, and closed-loop recovery.

The principal difference is the abstraction boundary. CRCL is primarily a high-level robot command language; IEEE 1872.1 and RoboEarth emphasize task knowledge and reasoning; ISO 22166 focuses on module information models; and SkiROS2, behavior trees, and PDDLStream supply particular planning and execution mechanisms. EISA places the relevant requirements at a single interface between EC and EAE: an instruction carries operation semantics, entity and resource bindings, preconditions, runtime invariants, success and failure predicates, a safety envelope, and a normalized result. It does not prescribe whether the lower layer uses behavior trees, search-based planning, learned policies, or classical control. EISA can therefore serve as a semantic interface over multiple planning and execution technologies.

9.4. Modular Embodied-Intelligence Development Frameworks

As foundation models enter robot systems, modularity is being used not only to organize conventional control software but also to compose cognitive models, skill models, and robot runtimes. REpac organizes reusable skills, a skill database, task control, a shared blackboard, knowledge management, and automated task planning as incrementally extensible modules, allowing industrial applications to evolve from predefined tasks toward autonomous planning [59]. RoboMatrix proposes a skill-centric hierarchy consisting of high-level orchestration, mid-level meta-skills, and low-level hardware, and addresses novel tasks through decomposition and meta-skill composition [60]. Both replace task-specific end-to-end development with stable, composable skill units, although their parameter, state, and completion semantics remain framework-specific.

To connect large models with robot software stacks, ROS-LLM integrates language-model agents with ROS, supports interchangeable execution modes such as inline programs and behavior trees, and allows atomic skills to be added by demonstration and refined through human or environmental feedback [61]. RAI provides configurable agents, connectors, and tools through which language models, multiagent systems, ROS 2, simulation, and digital twins can be composed as components [62]. RoboNeuron more directly addresses the mismatch between agent tool interfaces and robot middleware: it uses MCP and ROS 2 schemas to export callable tools automatically, while permitting model backends and runtime configurations to be replaced behind a stable reasoning boundary [63]. Together, these systems exemplify a modular development pattern for the foundation-model era: a high-level model orchestrates existing capabilities through tool or skill catalogs instead of being coupled to the entire robot codebase.

Other studies construct and evaluate complete embodied systems from replaceable modules. PFEA combines speech, open-vocabulary perception, vision–language planning, plan translation, action execution, and outcome evaluation in a loop that replans when a goal is not achieved [64]. OK-Robot takes a systems-first approach, combining vision–language semantic memory, navigation, and grasping modules with a state machine and showing that integration details materially affect real-world performance [65]. HomeRobot provides a simulator, a real-robot software stack, and an open-vocabulary mobile-manipulation benchmark with multiple implementations of its submodules, enabling perception, language understanding, navigation, and manipulation to be developed separately and reproduced end to end [66].

These frameworks and EISLH all use clear boundaries to reduce coupling and to let perception, planning, skills, control, and hardware evolve independently. Their scopes nevertheless differ. REpac, RoboMatrix, and PFEA mainly prescribe task or skill organization within a particular system; ROS-LLM, RAI, and RoboNeuron focus on connecting model tool calls to ROS or MCP; and OK-Robot and HomeRobot emphasize particular task pipelines and their evaluation. EISLH instead offers a reference boundary spanning user intent, cognitive compilation, semantic instructions, embodied execution, and hardware, with a transport-independent EISA that unifies capability negotiation, execution constraints, asynchronous state, and result evidence. These frameworks may implement EC or EAE, and they may transport EISA messages, but their modular APIs do not by themselves constitute cross-embodiment contracts for physical action.

9.5. Atomic Actions and Atomic Skills

An “atomic action” or “atomic skill” usually denotes a basic robot capability that can be trained, invoked, and composed independently, such as grasping, placing, moving, inserting, or rotating. The options framework formalizes temporally extended skills through an initiation set, an internal policy, and a termination condition [67]. Dynamic movement primitives represent motion as adaptable and reusable attractor systems [68]. Learning from demonstration and more recent work on atomic skill libraries address skill acquisition and data-efficient reuse, respectively [69,70]. Across these approaches, atomicity depends on the task, robot morphology, and skill implementation: the same term may refer either to a short motion primitive or to a local task containing its own perception–control loop.

EISA instructions are related to, but functionally distinct from, atomic skills. An atomic skill is a capability already possessed by a robot or to be learned; EISA specifies how an upper layer requests that capability, constrains its execution, and determines its outcome. The same EISA instruction may be implemented by different learned models, motion planners, or controllers, and a complex skill may be expanded into multiple EISA instructions. “Semantic atomicity” in this paper means only that an instruction has one principal physical effect and a decidable committed result. It does not mean that the underlying motion is uninterruptible or that physical side effects can be rolled back transactionally.

9.6. Foundation Models, Hierarchical Policies, and Cross-Embodiment Action Representations

Foundation-model-based robot planning has explored several interfaces between high-level semantics and physical action. SayCan selects actions by combining task relevance from a language model with affordance values from robot skills [16]. Code as Policies uses a language model to generate programs that call perception and control primitives [17]. Inner Monologue incorporates success detection, scene description, and human feedback into closed-loop high-level planning [18]. VoxPoser composes language-inferred affordances and constraints into three-dimensional value maps from which a model-based planner generates trajectories [71]. Each could implement part of EC, but its outputs are generally system-specific skill names, program interfaces, or spatial targets rather than a shared, cross-implementation execution contract.

For policy hierarchies, RT-H introduces fine-grained “language actions” as intermediate variables between task descriptions and low-level actions [35]. Hi Robot uses a high-level vision–language model to select the next skill and a low-level VLA to execute it, and evaluates the approach on multiple robot platforms [19]. Open X-Embodiment, Octo, and OpenVLA study transfer across observation and action spaces through cross-robot data and generalist policies [36,72,73]. These efforts provide empirical evidence for the value of intermediate action abstractions and cross-embodiment training.

UniAct further learns a universal action space for multiple robots and uses embodiment-specific decoders to generate concrete control actions [74]. Its “universal actions” and EISA both address action-space heterogeneity, but they are not equivalent. UniAct’s latent actions are learned from data and primarily target parameter sharing, representation transfer, and policy performance. EISA operations and contracts are defined by a specification and primarily target interpretable invocation, capability negotiation, version compatibility, constrained execution, and result auditing. The approaches can be complementary: an EAE could use a UniAct-like model to implement an EISA instruction, while EISA does not require different EAEs to share model parameters or a latent space.

9.7. OROCOS, ROS 2, and Execution Safety

OROCOS [75] and ROS 2 [9] primarily support robot-software component development, communication, integration, and operation. OROCOS emphasizes open, reusable real-time control components. ROS 2 provides node communication, discovery, quality-of-service policies, action interfaces, and lifecycle management. EISLH does not prescribe a messaging middleware or real-time component model; it specifies functional boundaries and semantic contracts from user intent to physical behavior. In one implementation, a ROS 2 action could transport EISA submissions and status events, while OROCOS components could implement parts of the real-time control inside EAE. Neither determines the target or result semantics of an EISA operation.

EISLH’s layered safety model is also related to work on runtime assurance and safety filters. A safety filter establishes a modular boundary between a high-performance controller that may be difficult to verify completely and a monitor or backup controller that can provide safety guarantees [40]. EISLH adopts the general separation of performance generation from safety enforcement but distributes responsibility among user-input filtering, EC-level task constraints, EAE-level real-time monitoring, and independent hardware safety circuits. The EISA safety envelope communicates non-relaxable task constraints across layers; it does not replace concrete mechanisms such as control barrier functions, reachability analysis, protective stops, or hardware emergency stops.

9.8. Synthesis and Comparison

Table 2 summarizes how the preceding work relates to EISLH. Existing research already covers hierarchical autonomy, task representation, skill execution, middleware, and cross-embodiment learning. Against this background, EISLH provides an end-to-end reference chain for embodied systems in the foundation-model era and treats the semantic interface between cognitive software and embodiment-specific execution as its principal object of standardization.

10. Conclusions and Outlook

Motivated by structural challenges in hardware heterogeneity, fragmented data, and tightly coupled models, this paper has proposed the Embodied Intelligence System Level Hierarchy (EISLH), drawing on the evolution of computer architecture. EISLH separates the full stack into five standardized levels: User Command and Physical Environment, the Embodied Compiler (EC), the Embodied Instruction Set Architecture (EISA), the Embodied Action Executor (EAE), and Embodied Hardware. The hierarchy is intended to provide a common architectural basis for decoupling cognitive planning, action instructions, and physical embodiments.

Deployment at scale will require coordinated progress in standardized protocols and open ecosystems [9,22,25]. Alongside stronger physical-semantic understanding and causal reasoning, future work should preserve a compact and stable core instruction set while improving capability descriptions, action-graph composition, embodiment and industry extensions, and disturbance resistance in low-level execution. As system-level specifications and horizontal specialization across the supply chain mature, embodied intelligence may overcome current engineering bottlenecks and move more rapidly into complex real-world applications.

Appendix A.1. Purpose, Scope, and Layer Boundaries

The main text divides an embodied-intelligence system into five layers: user commands and the physical environment, the Embodied Compiler (EC), the Embodied Instruction Set Architecture (EISA), the Embodied Action Executor (EAE), and embodied hardware. Building on that hierarchy, this appendix specifies an implementable and testable EISA v0.1.0. EISA does not require an EAE to use deterministic microprograms: an EAE may instead be implemented by a diffusion policy, a vision–language–action model (VLA), a model-predictive controller, or a hybrid of these approaches.

The boundaries of EISA are defined as follows.

• Upward, EISA is the target language of EC. It describes the finite physical operation to be completed, the objects involved, the target state, constraints, and a decidable result.
• Downward, EISA is the input contract of EAE. The EAE is responsible for perception-in-the-loop execution, action generation, embodiment-resource binding, trajectory and control solving, and hardware actuation.
• EISA does not specify neural-network architectures, prompt templates, joint counts, motor currents, servo periods, ROS 2 interfaces, EtherCAT/CAN buses, or message serialization formats.
• Coordinates, units, forces, time, tolerances, and safety boundaries carry cross-platform physical semantics and therefore belong to EISA. Joint indices, vendor-specific control modes, and bus addresses are outside the core semantics.

This specification uses MUST, SHOULD, and MAY to express normative strength. A core field is required for interoperability across implementations. A hint field expresses a preference and may be ignored by an EAE provided that hard constraints and target semantics remain intact.

Appendix A.2. Design Principles

Table A1. Design principles of EISA v0.1.0 and their realization in the specification

Principle	Realization in the specification
Clear layer boundaries	An instruction declares only the goal, conditions, and constraints of a physical operation; the action policy, controller, and hardware mapping are selected by the EAE.
Platform-independent semantics	The common core describes operations using entities, capability roles, reference frames, and physical quantities, without vendor interfaces, fixed joint arrays, or drive addresses.
Appropriate granularity	One instruction has one principal effect, a bounded scope, and a termination condition; long tasks are composed as directed acyclic action graphs.
Semantic orthogonality	Core operations are divided by principal effect: observation, navigation, reaching, grasping, release, carrying, force exertion, configuration, waiting, and stopping.
Explicit types	Every numeric value carries a unit; spatial quantities carry a reference frame, timestamp, and tolerance, and uncertainty where needed.
Decidable outcomes	An instruction explicitly states preconditions, invariants, success and failure predicates, and a deadline, and returns a normalized result.
Closed-loop execution	Entity references may bind to online tracks; during execution the EAE continually evaluates the goal, invariants, and safety conditions from observations.
Safety by construction	Common constraints cover velocity, acceleration, jerk, force/torque, collision, workspace, human–robot separation, and timeout.
Asynchronous execution	Submission, execution, control, and state subscription are separate; each instruction returns an execution handle and emits an event stream.
Capability negotiation	Before generating an action graph, the EC queries a capability description and validates operations, parameter domains, resources, predicates, and extension versions.
Separation of core and extensions	The common core remains stable across embodiments; a capability description declares platform capabilities, while namespaced extensions cover specialized embodiments, tools, and industrial operations.
Version compatibility	Backward compatibility is maintained within a major version. An incompatible change to an operation, field, or semantic rule increments the major version, and capability negotiation confirms the version range supported by both parties.
Transport independence	The specification defines abstract messages and idempotent semantics without binding to ROS 2, HTTP, shared memory, or a fieldbus.
Testability and traceability	Instructions, plans, and events have unique identifiers; capability snapshots, world-state versions, constraint triggers, and final evidence are recorded.

Table A1. Design principles of EISA v0.1.0 and their realization in the specification

Principle	Realization in the specification
Clear layer boundaries	An instruction declares only the goal, conditions, and constraints of a physical operation; the action policy, controller, and hardware mapping are selected by the EAE.
Platform-independent semantics	The common core describes operations using entities, capability roles, reference frames, and physical quantities, without vendor interfaces, fixed joint arrays, or drive addresses.
Appropriate granularity	One instruction has one principal effect, a bounded scope, and a termination condition; long tasks are composed as directed acyclic action graphs.
Semantic orthogonality	Core operations are divided by principal effect: observation, navigation, reaching, grasping, release, carrying, force exertion, configuration, waiting, and stopping.
Explicit types	Every numeric value carries a unit; spatial quantities carry a reference frame, timestamp, and tolerance, and uncertainty where needed.
Decidable outcomes	An instruction explicitly states preconditions, invariants, success and failure predicates, and a deadline, and returns a normalized result.
Closed-loop execution	Entity references may bind to online tracks; during execution the EAE continually evaluates the goal, invariants, and safety conditions from observations.
Safety by construction	Common constraints cover velocity, acceleration, jerk, force/torque, collision, workspace, human–robot separation, and timeout.
Asynchronous execution	Submission, execution, control, and state subscription are separate; each instruction returns an execution handle and emits an event stream.
Capability negotiation	Before generating an action graph, the EC queries a capability description and validates operations, parameter domains, resources, predicates, and extension versions.
Separation of core and extensions	The common core remains stable across embodiments; a capability description declares platform capabilities, while namespaced extensions cover specialized embodiments, tools, and industrial operations.
Version compatibility	Backward compatibility is maintained within a major version. An incompatible change to an operation, field, or semantic rule increments the major version, and capability negotiation confirms the version range supported by both parties.
Transport independence	The specification defines abstract messages and idempotent semantics without binding to ROS 2, HTTP, shared memory, or a fieldbus.
Testability and traceability	Instructions, plans, and events have unique identifiers; capability snapshots, world-state versions, constraint triggers, and final evidence are recorded.

Appendix A.3. Abstract Execution Model

An instruction is defined as the seven-tuple

$$I=\langle H,O,B,P,C,S,M\rangle ,$$

(A1)

where H is the version and trace header, O the operation, B the entity and resource bindings, P the operation-specific parameters, C the execution contract, S the safety envelope, and M non-normative metadata. The execution contract is further written as

$$C=\langle \mathrm{Pre},\mathrm{Inv},\mathrm{Goal},\mathrm{Fail},t_{max},\rho \rangle ,$$

(A2)

where $\mathrm{Pre}$ is the acceptance or start precondition, $\mathrm{Inv}$ an invariant that must hold at runtime, $\mathrm{Goal}$ the success predicate, $\mathrm{Fail}$ an explicit failure predicate, $t_{max}$ the timeout, and $\rho$ the closed-loop policy for invalid references, uncertain observations, or local infeasibility.

Let $x_t$ denote the joint environment–robot state, $z_t$ the observation, and $\pi (a_t\mid z_{\le t},I)$ the internal policy of the EAE. EISA constrains only the admissible set of execution trajectories:

$$\begin{array}{cc}\hfill \mathrm{Pre}\left(x_{t_0}\right)& =\mathrm{true},\hfill \end{array}$$

(A3)

$$\begin{array}{cc}\hfill \mathrm{Inv}\left(x_t\right)& =\mathrm{true},t_0\le t<t_f,\hfill \end{array}$$

(A4)

$$\begin{array}{cc}\hfill \mathrm{Goal}\left(x_{t_f}\right)& =\mathrm{true},t_f-t_0\le t_{max}.\hfill \end{array}$$

(A5)

Different EAEs may therefore generate different action sequences, provided that they satisfy the same semantic contract. If the available observations do not establish success, the EAE must not return success merely because an action was issued. It should continue observing, return a result with uncertainty, or fail with GOAL_UNVERIFIED.

Principal-effect rule

Each core operation defines exactly one principal physical effect. For example, GRASP establishes a controlled grasping relation but does not imply lifting; lifting or carrying is expressed by a subsequent CARRY. This rule avoids multiple encodings of the same action and allows the EC to localize and recover from failures.

Semantic atomicity

“Atomic” means that an instruction has a single decidable committed result, not that the hardware state can be rolled back. When an instruction fails, the EAE must report physical side effects that have already occurred and the currently observable state. The EC may generate compensating instructions from this information but must not assume automatic transactional rollback.

Appendix A.4. Common Type System

Appendix A.4.1. Physical Quantities, Units, and Time

Every physical quantity is represented as

$$q=\{\mathrm{value}:r,\mathrm{unit}:u\}$$

(A6)

An implementation must support the canonical SI units and may accept the common equivalent units listed in Table A2. In logs and results, the EAE should echo the canonical unit actually used.

Table A2. Core physical quantities and canonical units

Type	Canonical unit	Examples of accepted explicit units
Length/distance	m	mm, cm, m
Translational speed/acceleration/jerk	m/s, m/s2, m/s3	A unit must accompany the value
Angle/angular speed	rad, rad/s	deg, deg/s
Force/torque	N, N*m	The unit must not be omitted
Mass/temperature	kg, K	g or degC may be supplied and normalized by the receiver
Duration	s	ms, s, min
Time point	UTC/TAI timestamp	The time scale must be declared; a monotonic clock is used only for durations within one execution session

Table A2. Core physical quantities and canonical units

Type	Canonical unit	Examples of accepted explicit units
Length/distance	m	mm, cm, m
Translational speed/acceleration/jerk	m/s, m/s2, m/s3	A unit must accompany the value
Angle/angular speed	rad, rad/s	deg, deg/s
Force/torque	N, N*m	The unit must not be omitted
Mass/temperature	kg, K	g or degC may be supplied and normalized by the receiver
Duration	s	ms, s, min
Time point	UTC/TAI timestamp	The time scale must be declared; a monotonic clock is used only for durations within one execution session

Units must be present even for zero values. An implementation must not infer degrees or radians from a numeric range.

Appendix A.4.2. Reference Frames and Spatial Types

Core spatial types include Vector3, Quaternion, PoseSE3, Twist6, Wrench6, Region3D, and PoseDistribution. Every spatial quantity must contain:

• frame: a stable identifier of the reference frame, such as world/map, entity/rack, or a semantic robot frame published in the capability description;
• stamp: the observation time to which the value applies;
• value: the numerical value and unit;
• tolerance: the positional and orientational tolerance used to determine whether the goal has been reached; and
• covariance (optional): a covariance when the spatial estimate has material uncertainty.

Quaternions are ordered as $(x,y,z,w)$ and must be normalized. world/map is not a hard-coded string but a globally stable frame role declared in the capability description. The EC should not assume that a transform is always available between arbitrary frames. If a transform satisfying the freshness and uncertainty requirements cannot be obtained, the EAE must reject or pause the affected instruction.

Appendix A.4.3. Entity References and Resource Selectors

Listing 1: Normalized example of an entity reference and resource selector

EntityRef.id must be unique within an execution session. A natural-language description may be included as a debugging label but cannot replace a disambiguated identifier. If an entity is occluded, merged, split, or reidentified, the EAE should emit a REFERENCE_UPDATED event. If identity uncertainty exceeds the permitted threshold, the EAE follows $\rho$ in the contract.

A ResourceSelector selects a capability role rather than a fixed joint or device. For example, it may request “any end effector capable of safely grasping a soft object.” The EAE decides whether this binds to the left hand, right hand, or both and reports the binding in a RESOURCE_BOUND event. Only an embodiment-extension namespace may expose joint-level diagnostic or calibration interfaces; core instructions must not include dimension-dependent parameters such as joint_R_n.

Appendix A.4.4. Goal Predicates

Success, failure, preconditions, and invariants are represented by composable predicates. The core predicates are listed in Table A3.

Table A3. Core observable predicates

Predicate	Semantics
pose_in(e,r,tol)	The pose of entity or resource e lies within the tolerance of region or target r.
relation(e1,rel,e2)	The two entities satisfy a negotiated relation such as on, inside, near, hanging_from, or visible_to.
grasped(e,resource)	A controlled grasp between the object and execution resource satisfies holding-force and stability requirements.
contact(e1,e2,state)	Contact is none, touching, sliding, or stable.
wrench_in(target,range)	Contact force/torque lies within the specified range.
property(e,key,value,tol)	A measurable physical property or discrete state meets the target, such as a door-opening angle or button state.
clearance(e,set,d)	The minimum clearance between an entity and an obstacle set is at least d.
stable(e,margin)	The entity or robot satisfies the agreed static or dynamic stability margin.
observed(e,fields,age,confidence)	The required fields have been observed within the freshness and confidence thresholds.
event(name,filter)	A normative event declared in the capability description has been received.

Table A3. Core observable predicates

Predicate	Semantics
pose_in(e,r,tol)	The pose of entity or resource e lies within the tolerance of region or target r.
relation(e1,rel,e2)	The two entities satisfy a negotiated relation such as on, inside, near, hanging_from, or visible_to.
grasped(e,resource)	A controlled grasp between the object and execution resource satisfies holding-force and stability requirements.
contact(e1,e2,state)	Contact is none, touching, sliding, or stable.
wrench_in(target,range)	Contact force/torque lies within the specified range.
property(e,key,value,tol)	A measurable physical property or discrete state meets the target, such as a door-opening angle or button state.
clearance(e,set,d)	The minimum clearance between an entity and an obstacle set is at least d.
stable(e,margin)	The entity or robot satisfies the agreed static or dynamic stability margin.
observed(e,fields,age,confidence)	The required fields have been observed within the freshness and confidence thresholds.
event(name,filter)	A normative event declared in the capability description has been received.

Predicates may be composed with all_of, any_of, and not. A hold_for duration may require a predicate to remain continuously true to suppress sensor noise. An implementation must not execute arbitrary scripts as predicates; a custom predicate must declare its inputs, outputs, tolerances, and observational evidence through an extension namespace.

Appendix A.5. Common Instruction Envelope

Table A4 defines the fields shared by all core instructions.

Table A4. Common EISA instruction envelope

Field	Type	Req.	Semantics
eisa_version	Version	Required	Semantic version used by this instruction, for example 0.1.
instruction_id	UUID	Required	Globally unique and never reused; supports idempotent submission, logging, and replay.
plan_id	UUID	Required	Identifier of the containing action graph; a standalone execution also has its own plan identifier.
parent_id	UUID/null	Optional	Parent task, recovery action, or compound node that generated this instruction.
opcode	QName	Required	Core operation or namespaced extension operation.
bindings	Map	Required	Entity references, semantic resource selectors, and runtime binding rules.
parameters	Object	Required	Strongly typed, operation-specific parameters; an empty object when there are none.
contract	Contract	Required	Preconditions, invariants, success/failure predicates, timeout, and closed-loop policy.
safety	SafetyEnvelope	Required	Hard safety envelope for this instruction; a lower-level policy must not relax it.
priority	Integer	Optional	Scheduling hint for preemptible resources only; it cannot override safety priority.
deadline	Timestamp	Optional	Absolute start/completion limit; if a relative timeout is also given, the stricter limit applies.
required_features	QName list	Optional	Absence of any listed feature requires rejection.
preferences	Object	Optional	Ignorable path, posture, modality, or resource preferences.
metadata	Object	Optional	Non-normative information such as source text or debugging labels; it must not alter execution semantics.

Table A4. Common EISA instruction envelope

Field	Type	Req.	Semantics
eisa_version	Version	Required	Semantic version used by this instruction, for example 0.1.
instruction_id	UUID	Required	Globally unique and never reused; supports idempotent submission, logging, and replay.
plan_id	UUID	Required	Identifier of the containing action graph; a standalone execution also has its own plan identifier.
parent_id	UUID/null	Optional	Parent task, recovery action, or compound node that generated this instruction.
opcode	QName	Required	Core operation or namespaced extension operation.
bindings	Map	Required	Entity references, semantic resource selectors, and runtime binding rules.
parameters	Object	Required	Strongly typed, operation-specific parameters; an empty object when there are none.
contract	Contract	Required	Preconditions, invariants, success/failure predicates, timeout, and closed-loop policy.
safety	SafetyEnvelope	Required	Hard safety envelope for this instruction; a lower-level policy must not relax it.
priority	Integer	Optional	Scheduling hint for preemptible resources only; it cannot override safety priority.
deadline	Timestamp	Optional	Absolute start/completion limit; if a relative timeout is also given, the stricter limit applies.
required_features	QName list	Optional	Absence of any listed feature requires rejection.
preferences	Object	Optional	Ignorable path, posture, modality, or resource preferences.
metadata	Object	Optional	Non-normative information such as source text or debugging labels; it must not alter execution semantics.

If a repeated submission with the same instruction_id has the same content digest, the EAE must return the original execution handle. If the digest differs, it must reject the request with IDEMPOTENCY_CONFLICT. This rule preserves consistent EISA behavior over transports that provide only at-least-once delivery.

Appendix A.6. Core Instruction Set

EISA v0.1.0 defines ten core instructions. They are semantic operations, not integer encodings; their textual names are the normative identifiers. Table A5 gives an overview, followed by precise definitions.

Table A5. Overview of the EISA v0.1.0 core instructions

Operation	Principal effect	Platform-independent semantics
OBSERVE	Update observation	Acquire properties and confidence values for specified entities or regions.
NAVIGATE	Move the robot	Bring a robot reference frame to a target pose, region, or relative location.
REACH	Move an execution resource	Bring an end effector or tool to a target without creating or releasing a grasp.
GRASP	Establish a grasp	Establish a verifiable controlled grasp between an execution resource and an object.
RELEASE	Release a grasp	Remove a specified grasp relation and verify that the object does not unintentionally follow the resource.
CARRY	Carry an object	Bring an object to a spatial target while maintaining specified grasp or support relations.
EXERT	Apply contact action	Apply bounded force/torque to a target until a target physical predicate is satisfied.
CONFIGURE	Change embodiment configuration	Change posture or morphology toward a semantic configuration goal while maintaining specified relations.
WAIT	Await a condition	Introduce no new principal physical effect until an event, predicate, or duration is satisfied.
HALT	Stop in a controlled manner	Stop a specified execution scope and enter a declared safe holding state.

Table A5. Overview of the EISA v0.1.0 core instructions

Operation	Principal effect	Platform-independent semantics
OBSERVE	Update observation	Acquire properties and confidence values for specified entities or regions.
NAVIGATE	Move the robot	Bring a robot reference frame to a target pose, region, or relative location.
REACH	Move an execution resource	Bring an end effector or tool to a target without creating or releasing a grasp.
GRASP	Establish a grasp	Establish a verifiable controlled grasp between an execution resource and an object.
RELEASE	Release a grasp	Remove a specified grasp relation and verify that the object does not unintentionally follow the resource.
CARRY	Carry an object	Bring an object to a spatial target while maintaining specified grasp or support relations.
EXERT	Apply contact action	Apply bounded force/torque to a target until a target physical predicate is satisfied.
CONFIGURE	Change embodiment configuration	Change posture or morphology toward a semantic configuration goal while maintaining specified relations.
WAIT	Await a condition	Introduce no new principal physical effect until an event, predicate, or duration is satisfied.
HALT	Stop in a controlled manner	Stop a specified execution scope and enter a declared safe holding state.

Appendix A.6.1. OBSERVE: Active Observation

Parameters

targets is a list of entities or spatial regions, and fields identifies the properties to update. freshness, min_confidence, and max_uncertainty specify quality requirements. viewpoint may specify an admissible viewing region or angle constraint but must not name a particular sensor index.

Semantics

The EAE may rotate a sensor, adjust the embodiment, or fuse multimodal observations, but it must not implicitly perform large-scale navigation or alter the state of an environment object. If leaving the current work area is necessary, it should return VIEWPOINT_UNREACHABLE so that the EC can generate an explicit NAVIGATE instruction.

Success and failure

The instruction succeeds when every required field is observed within the quality thresholds. The result includes values, units, timestamps, reference frames, confidence, and evidence references. It fails if the target does not exist, its identity cannot be disambiguated, observation times out, or a required property is not measurable.

Appendix A.6.2. NAVIGATE: Robot Navigation

Parameters

goal is an absolute or relative pose, a spatial region, or a semantic relation such as near(coat). arrival_tolerance specifies the arrival tolerance, and maintain specifies relations that must be preserved during navigation. mode may appear only as a capability role or preference, such as ground, stairs, or any; wheel speeds and gait phases are not permitted.

Semantics

This instruction changes the robot’s global support or base frame. Wheeled, legged, aerial, and hybrid embodiments share the same semantics: each must bring its reference frame to the specified target. The capability description and EAE determine whether the implementation uses rolling, walking, flying, or another locomotion method.

Success and failure

The instruction succeeds when the robot reaches the goal within the prescribed tolerance and remains there for hold_for. It fails on infeasibility, loss of localization, violation of a safety invariant, persistent path blockage, or timeout, and returns the final pose and evidence of blockage.

Appendix A.6.3. REACH: Execution-Resource Reaching

Parameters

resource is a semantic resource selector; goal is a pose, region, or relative relation for the end effector or tool. maintain declares grasp, visibility, and stability relations that must be preserved. contact_policy is forbid, allow_target, or a negotiated policy.

Semantics

The EAE independently decides which hand to use, how many degrees of freedom to coordinate, and whether whole-body coordination is required. The instruction neither creates a new grasp nor releases an existing one. Thus, “bring a hand near the coat” and “grasp the coat” are represented by REACH and GRASP, respectively.

Success and failure

The instruction succeeds when the resource frame reaches the goal while all maintain constraints hold. It fails because of a singular configuration, unavailable resource, unintended contact, insufficient stability, or loss of target tracking.

Appendix A.6.4. GRASP: Establishing a Grasp

Parameters

object is a unique entity reference, and resource is an end-effector capability selector. grasp_intent is a negotiated semantic intent such as hold, pinch, power, or support. allowed_regions identifies permissible contact regions, while handling describes material, fragility, deformability, and the admissible contact-force range.

Semantics

GRASP establishes a maintainable controlled relation but does not require the object to leave its support surface. If a reaching motion is needed before grasping, the EAE may make the necessary local, bounded end-effector adjustment. Motion across a workspace must be expressed by an explicit REACH or NAVIGATE instruction.

Success and failure

The instruction succeeds after the grasp relation has been verified from force, vision, or other evidence declared in the capability description and has persisted for the specified duration. It fails on slip, force-limit violation, grasping the wrong object, an inadmissible object state, or insufficient grasp quality.

Appendix A.6.5. RELEASE: Releasing a Grasp

Parameters

object and relation_id identify the grasp to release. support_required states the support relation that the object must satisfy before release. separation specifies a minimum post-release clearance or a no-following requirement.

Semantics

The instruction releases only the specified grasp; it does not imply placement, withdrawal, or a success notification to the upper layer. To “place a cup on a table,” the EC should first use CARRY to bring the cup to a pre-placement goal, then use RELEASE to remove the grasp, and finally verify on(cup,table) through a result predicate or OBSERVE.

Success and failure

The instruction succeeds when the grasp has been released, the object no longer follows the execution resource, and the required support relation holds. It fails because of adhesion, failure of the gripper to open, risk of the object falling, missing support, or an identity mismatch.

Appendix A.6.6. CARRY: Controlled Carry

Parameters

object is the carried entity, and goal is its final pose, region, or relation. maintain contains at least one existing grasp or support relation. handling may specify orientation preservation, spill prevention, acceleration limits, and fragility; route_constraints describes permitted and prohibited workspaces.

Semantics

The principal effect is a change in the object’s spatial state rather than the robot’s. The EAE may coordinate the arms, torso, and mobile base, but it must not release or switch the grasp unless declared. If the required distance exceeds the current capability envelope, the EAE may reject the instruction so that the EC can decompose the task into navigation, local carrying, or a handover extension.

Success and failure

The instruction succeeds when the object’s goal predicate holds, maintain relations remain intact, and the safety envelope has been satisfied throughout execution. It fails on slip, collision, violation of a handling constraint, target infeasibility, or loss of the grasp relation.

Appendix A.6.7. EXERT: Bounded Contact Action

Parameters

target is the entity on which the action is exerted, and contact_region is the permitted region of contact. wrench_goal specifies force/torque direction and target range. effect_goal is an observable state to be produced by the action, such as a depressed button, a door angle within a range, or a surface-wiping coverage threshold. interaction may be push, pull, press, twist, or a negotiated mode.

Semantics

EXERT controls an execution resource as it establishes contact with the target entity and applies force or torque within safety constraints until effect_goal holds. The instruction specifies the target entity, contact region, action range, and intended outcome, but not a joint motion or low-level control method. wrench_goal is a contact-action target or limit, not a motor or joint drive command. The EAE selects the execution resource and handles contact establishment, impedance adaptation, and low-level force control according to embodiment capabilities and real-time feedback. EXERT does not imply global navigation, object transport, or the establishment or release of a grasp.

Success and failure

The instruction succeeds when effect_goal is achieved without exceeding the force/torque limits. It fails if contact cannot be established, the target state does not change, a force limit is exceeded, abnormal compliance is detected, or execution times out.

Appendix A.6.8. CONFIGURE: Semantic Embodiment Configuration

Parameters

configuration is a semantic configuration or effect constraint published in the capability description, such as crouched, upright, or dual_arm_workspace_high. maintain declares end-effector poses, grasps, and center-of-mass stability relations that must be preserved. body_region restricts the embodiment region that may be reconfigured.

Semantics

This instruction replaces the joint-count-dependent ADJP [joint_R_n]. The EC expresses the required configuration effect, and the EAE maps it to a joint or morphological configuration for the particular embodiment. If joint values must be specified for calibration or maintenance, an explicit hardware extension should be used instead of core EISA.

Success and failure

The instruction succeeds when the semantic configuration goal and all maintain relations hold simultaneously. It fails if the configuration is unavailable, the stability margin is inadequate, maintain relations conflict, or a joint or mechanism fails.

Appendix A.6.9. WAIT: Conditional Waiting

Parameters

At least one of until and duration must be supplied. If both appear, completion=any/all specifies their composition. timeout is always a hard upper bound.

Semantics

WAIT introduces no new principal physical effect, but the EAE continues to observe invariants and safety state. It must not replace completion detection for another action. Submitting a fixed millisecond wait for NAVIGATE is nonconforming; the caller should subscribe to that navigation instruction’s terminal state or create a dependency edge in the action graph.

Success and failure

The instruction succeeds when the waiting condition satisfies the composition rule. It fails on timeout, loss of a required event source, or a safety state that requires termination.

Appendix A.6.10. HALT: Controlled Stop

Parameters

scope denotes an instruction, a resource set, a plan, or the entire robot. stop_mode is controlled, protective, or emergency. posture specifies a permitted holding or unloading state after the stop.

Semantics

HALT is a stop action that can be explicitly submitted and traced within a plan. An out-of-band hardware emergency stop has higher priority and does not depend on successful delivery of a HALT message. HALT is not equivalent to cancellation: cancellation is a control-plane operation, whereas HALT declares a physical stopped state that must be reached.

Success and failure

The instruction succeeds when all motion and force application in scope have stopped and the requested safe holding state has been reached. If safety can be achieved only through a higher-level protective stop, the result should report physical success while marking the degradation and its trigger.

Appendix A.7. Safety Envelope and Constraint Priority

Every instruction that may produce motion or contact must carry a SafetyEnvelope. A plan may provide a default envelope; an individual node may tighten but not relax it. The core fields are listed in Table A6.

Table A6. Common safety envelope

Field	Semantics
kinematic_limits	Maximum translational/angular velocity, acceleration, angular acceleration, and jerk.
wrench_limits	Maximum force, torque, impulse, and contact pressure by object, resource, or contact region.
workspace	Permitted regions, prohibited regions, soft boundaries, and boundary reference frames.
collision_policy	Prohibited collision sets, allowed contact pairs, minimum clearances, and self-collision policy.
human_safety	Human-body zones, dynamic minimum distance, approach speed, and contact types requiring authorization.
stability	Support, tipping, grasp, and payload stability margins.
timeout	Maximum action duration and communication-loss watchdog.
on_violation	At least one of controlled_stop, protective_stop, or emergency_stop.

Table A6. Common safety envelope

Field	Semantics
kinematic_limits	Maximum translational/angular velocity, acceleration, angular acceleration, and jerk.
wrench_limits	Maximum force, torque, impulse, and contact pressure by object, resource, or contact region.
workspace	Permitted regions, prohibited regions, soft boundaries, and boundary reference frames.
collision_policy	Prohibited collision sets, allowed contact pairs, minimum clearances, and self-collision policy.
human_safety	Human-body zones, dynamic minimum distance, approach speed, and contact types requiring authorization.
stability	Support, tipping, grasp, and payload stability margins.
timeout	Maximum action duration and communication-loss watchdog.
on_violation	At least one of controlled_stop, protective_stop, or emergency_stop.

Constraint priority, from highest to lowest, is: hardware emergency stops and regulatory limits; the embodiment safety supervisor; non-relaxable limits in the capability description; hard instruction constraints; action goals; and execution preferences. Model confidence, user priority, and task utility must never override a higher-priority safety constraint. If the EAE cannot establish that a hard constraint can be monitored and enforced, it must reject the instruction with CONSTRAINT_UNENFORCEABLE before action begins rather than silently degrading it.

EISLH assigns safety responsibilities across layers. The user-command and physical-environment layer filters inputs for permission, legality, and ethical risk. The EC checks task feasibility against the capability description and generates task-level safety constraints. The EAE continuously monitors and enforces the safety envelope during execution. Hardware safety supervisors and independent emergency-stop circuits handle software failure or severe physical risk. Passing an upper-layer check does not permit a lower layer to omit its own safety validation, and no lower layer may relax a hard constraint declared above it. In brief, the user layer asks whether the task may be requested; the EC asks whether the current robot can complete it under the stated constraints; the EAE asks whether execution can continue safely in the current environment; and the hardware layer ensures that dangerous behavior can still be stopped after software failure.

Appendix A.8. Asynchronous Submission, State Machine, and Results

The EISA abstract interface includes at least discover, submit, inspect, subscribe, cancel, pause, and resume. These are control-plane operations rather than physical operations. After schema validation and basic capability checking, submit immediately returns an ExecutionHandle; it must not wait for a long-running action to complete.

$$\begin{array}{cc}\hfill \mathtt{SUBMITTED}& \to \{\mathtt{ACCEPTED},\mathtt{REJECTED}\},\hfill \\ \hfill \mathtt{ACCEPTED}& \to \mathtt{QUEUED}\to \mathtt{RUNNING},\hfill \\ \hfill \mathtt{RUNNING}& \leftrightarrow \mathtt{PAUSED},\hfill \\ \hfill \{\mathtt{QUEUED},\mathtt{RUNNING},\mathtt{PAUSED}\}& \to \{\mathtt{SUCCEEDED},\mathtt{FAILED},\mathtt{CANCELLED},\mathtt{TIMED}\_\mathtt{OUT}\}.\hfill \end{array}$$

(A7)

Terminal states are irreversible. REJECTED means that action did not begin; FAILED means that it may already have produced partial physical effects. A cancellation request is best-effort and must await confirmation of a safe stop. The client must not assume that the robot has stopped before receiving that confirmation.

Appendix A.8.1. Events and Progress

Every event contains at least event_id, instruction_id, a monotonically increasing sequence, timestamp, state, progress, evidence, and world_revision. Core events cover state changes, resource binding, reference updates, provisional goal attainment, approaching or triggering a constraint, recovery attempts, and final results. Progress is a hint and cannot replace terminal-state evaluation.

Appendix A.8.2. Normalized Result

Listing 2: Normalized execution result

The example’s NTFY status_code=EXEC_SUCCESS is not treated as an action instruction. The EAE automatically emits a terminal success or failure event from the contract, preventing the EC from instructing the executor in advance to declare success.

Appendix A.8.3. Error Taxonomy

Error codes have two levels: a stable category and extensible details.

• INVALID.*: schema, type, unit, frame, predicate, or idempotency conflict;
• UNSUPPORTED.*: unsupported version, operation, extension, resource, or parameter domain;
• REFERENCE.*: unresolved entity, identity ambiguity, stale world version, or unavailable frame transform;
• PRECONDITION.*: unsatisfied precondition or resource conflict;
• PERCEPTION.*: insufficient observation quality, lost tracking, or unmeasurable property;
• PLANNING.*: unreachable target or no feasible path, grasp, or configuration;
• EXECUTION.*: goal not reached, slip, unintended contact, localization loss, or exhausted local recovery;
• SAFETY.*: triggered collision, human-distance, force, stability, workspace, or other invariant;
• HARDWARE.*: actuator, sensor, power-supply, or emergency-stop fault;
• TIMEOUT.* and CANCELLED.*: temporal or control-plane termination; and
• INTERNAL.*: uncategorized implementation failure, accompanied by a traceable diagnostic identifier.

Appendix A.9. Capability Discovery and Negotiation

Before compiling an action graph, the EC must obtain the CapabilityProfile corresponding to the current robot, tools, and operating mode. A capability description may be cached, but its content digest must accompany submission. If the digest is stale or capabilities have changed, the EAE returns CAPABILITY_PROFILE_STALE with the new digest.

A capability description contains at least:

• the supported EISA major/minor version range and required features;
• availability, parameter schema, physical ranges, supported predicates, and concurrently usable resources for each operation;
• semantic reference frames, sensing modalities, end-effector resource roles, and available tools;
• non-relaxable embodiment safety limits for speed, force, workspace, and related quantities;
• the core relation and event vocabularies and the extension namespaces and versions; and
• dynamic conditions such as payload, installed tools, environment class, or authorization mode.

Listing 3: Excerpt from a capability description

The EC may generate hard constraints only within the ranges allowed by the capability description. An out-of-range preference may be clipped with a warning; an out-of-range hard constraint must be rejected before execution.

Appendix A.10. Action Graphs and Long-Horizon Composition

A long task is represented by an ActionGraph, rather than by placing several principal effects in one “large instruction.” An action graph is a finite directed acyclic graph $G=(V,E)$ in which every node $v\in V$ is a core or extension instruction and every edge defines a start condition. Core edge types are:

• AFTER_SUCCESS: start after the predecessor succeeds;
• AFTER_TERMINAL: start after the predecessor reaches any terminal state;
• WHEN: start when a specified world predicate holds;
• JOIN_ALL / JOIN_ANY: join parallel branches; and
• ON_ERROR(code): start a recovery node when an error category matches.

Nodes may inherit the graph-level eisa_version, plan_id, and default safety envelope. After expansion, each node must still form the complete envelope defined in Table A4; instruction_id cannot be inherited or omitted. For readability, a node may additionally have a plan-local node_id, which dependency edges reference.

Nodes may execute in parallel, but the EAE must check conflicts using the resources actually bound. The EC must not use parallel nodes to bypass mutual exclusion or safety constraints on the same resource. The graph-level policy states whether a failure stops unstarted nodes, permits unrelated branches to continue, or enters an explicit recovery branch. There is no implicit unbounded retry.

Appendix A.11. Closed-Loop Policy, World Versioning, and Recovery

Each instruction’s contract.policy may declare at least:

• on_target_motion: track, freeze_snapshot, or abort;
• on_occlusion: actively observe again within a bounded interval, pause, or fail;
• on_local_blockage: replan locally within the safety envelope or return immediately;
• max_recovery_attempts: a finite number of local recovery attempts; and
• revalidate: conditions that must be rechecked before starting and before critical contact.

Local recovery may change only the implementation path; it cannot change the principal goal, relax a safety constraint, substitute an unauthorized object, or introduce a new principal physical effect. For example, GRASP may adjust the grasp point within an allowed contact region but cannot independently move the target object to another room. When the bounds of local recovery are exceeded, the instruction must fail so that the EC can recompile.

Every instruction that depends on environment state carries a world_revision. The EAE may use newer observations but must record in events the differences between the compilation snapshot and the execution snapshot. If a difference materially changes a precondition, object identity, or safety judgment, the instruction must be revalidated or rejected rather than executed mechanically from stale coordinates.

Appendix A.12. Versioning, Extensions, and Transport Independence

Versions use the MAJOR.MINOR.PATCH format and follow the rule that backward compatibility is preserved within a major version, whereas an incompatible change increments the major version:

• MAJOR: an incompatible change to an operation or field semantic;
• MINOR: addition only of optional fields, operations, predicates, or result information; and
• PATCH: corrections and textual clarification that do not alter observable semantics.

Within a major version, a receiver must ignore unknown optional metadata but must not ignore an unknown required field or required_features. A sender must not assume that a feature introduced in a minor version is present unless capability negotiation explicitly confirms support.

Extension operations use reverse-domain or organizational-domain names, for example org.example.process/INSERT_CONNECTOR@1.0. Every extension must publish its type schema, preconditions, principal effect, success/failure conditions, safety constraints, result fields, resource requirements, and degradation policy. An extension must neither change the semantics of a core operation nor conceal vendor-private binary data in a core field. An unknown required extension must be rejected.

This specification defines only abstract messages and their idempotency, ordering, and state semantics. ROS 2 actions, gRPC, HTTP, shared memory, or other mechanisms may transport the same interface. A transport adapter must preserve instruction_id, event sequence numbers, cancellation acknowledgment, and terminal-state consistency. Fieldbuses such as EtherCAT and CAN lie between the EAE and hardware and do not directly carry core EISA semantics.

Appendix A.13. Traceability, Replay, and Conformance Testing

The EAE must preserve an immutable trace for every instruction. At minimum, the trace includes the original instruction digest, capability-profile digest, actual resource bindings, world-state versions, key observational evidence, model/controller implementation identifiers, random seed when available, constraint margins, state transitions, recovery attempts, final result, and physical side effects. Access control may protect private log data but must not compromise event ordering or result verifiability.

Replay has two forms:

• Semantic replay: resubmit the same goals and constraints, allowing the EAE to produce different but contract-equivalent actions.
• Diagnostic replay: rerun the implementation over a recorded observation stream to compare state decisions and action outputs; this does not guarantee reproduction of the physical trajectory.

Conformance tests cover at least schema, unit, and frame validation; boundary parameters; unknown required features; idempotent resubmission; achieved and unverified goals; cancellation/pause races; safety-constraint triggers; stale entity references; capability changes; parallel resource conflicts; error-code stability; and event-sequence continuity. Passing the core conformance tests establishes only interface and semantic conformance; it does not imply that a robot possesses physical capabilities absent from its capability description.

Appendix A.14. Complete Example: Hanging a Coat from the Sofa on a Rack

The task illustrated in the main text is rewritten below as an EISA v0.1.0 semantic action graph. To emphasize instruction structure, the example omits some repeated safety fields; in an actual submission, every node inherits the graph-level safety envelope. The example deliberately contains no joint angles, fixed arm indices, fixed millisecond waits, obstacle-avoidance switch, or explicit success notification. Each node inherits the graph-level version, plan identifier, and safety envelope but still has an independent UUID; node_id is used only by dependency edges in the example.

Listing 4: EISA v0.1.0 action graph for the coat-hanging task (excerpt)

The nodes in the graph may still use a diffusion model or VLA to generate continuous actions. The EC fixes only the entities, target relations, boundaries, and acceptance conditions. The EAE may select the gait, arm, grasp point, and control trajectory from real-time obstacles, coat deformation, and embodiment state. If the final hanging_from relation cannot be verified, the action graph terminates with a localized verification failure rather than reporting the entire task as successful merely because RELEASE was executed.

Appendix A.15. Normative Design Summary

EISA v0.1.0 separates semantic goals and verifiable constraints from model, control, and hardware implementation. The EC compiles finite physical operations with unambiguous entities, types, and outcomes; the EAE generates and executes actions in closed loop within embodiment capabilities and the safety envelope. A small core instruction set, explicit execution contracts, an asynchronous state machine, capability negotiation, and namespaced extensions together form a stable software–hardware interface. They allow a task to migrate across embodiments while diffusion models, VLAs, and conventional controllers evolve without changing upper-layer semantics.