In robotic manipulation research, Vision-Language-Action (VLA) models and World Action Models (WAM) provide robots with different pathways for action generation. However, when a task extends from a single pick-and-place operation to continuous construction and bimanual coordination, success depends not only on whether the current action can be completed, but also on whether the conditions established earlier can continue to support subsequent execution.
An action has clearly succeeded. Why, then, can the entire task still fail at the next step? What the robot truly lacks is a stronger action model, or a system for organizing those actions?
To address this question, a research team from The Chinese University of Hong Kong, Shenzhen, in collaboration with A*STAR in Singapore, Tsinghua University, and other institutions, proposed LOGIV, introducing Graph Engineering into the execution architecture of agentic robots. Building on existing VLA and WAM policies, LOGIV constructs an explicit task graph that transforms conditional dependencies and resource orderings between actions into an execution basis that can be inspected, tracked, and repaired.
LOGIV shifts the system’s focus from whether a particular action has been completed to whether the subsequent plan remains valid. Through graph dependency verification and causal local repair, the robot can restore necessary supporting conditions after detecting that a condition has become invalid, preserve the portions of the plan that remain usable, and then continue toward the goal. Without adding any new trainable components at this layer, the task graph can genuinely participate in the robot’s execution decisions.
Paper title: LOGIV: Graph-Verified Execution with Causal Local Repair for Long-Horizon Robot Tasks
Full paper: https://arxiv.org/abs/2610.40016
Project page: https://enqiao-lu.github.io/logiv-project/
Code and demonstrations: https://github.com/Enqiao-Lu/LOGIV
Advancing Long-Horizon Execution: From Actions to Dependencies
Having a robot build a block bridge does not sound complicated: position the supports on both sides, pick up the crossbeam, and place the crossbeam on top. But what if the robot accidentally knocks the previously positioned support out of alignment while picking up the crossbeam?
The grasping action succeeded, and the preceding placement action was indeed completed, yet the conditions required for the next step no longer hold. If the robot continues following the plan, it is likely to place the crossbeam on a support point that no longer exists. This is precisely a hidden problem in long-horizon physical interaction. The completion of an action is part of history, but the conditions produced by that action may become invalid at any time. If the system records only task progress without checking whether these conditions still hold, past successes may conceal current risks.
If a long task is written as a to-do list, the robot knows what to do first and what to do next. If it is organized as a task graph, the robot can also ask what the next step depends on and which subsequent actions can no longer continue if a particular condition becomes invalid. LOGIV accordingly brings Graph Engineering down to the execution layer, organizing the task into a directed acyclic graph containing two types of dependencies.
Task nodes: These correspond to high-level subtasks such as grasping and placing, and also include the starting point and final goal of the task.
Conditional support edges: These record which action establishes a condition required by a subsequent action—for example, the crossbeam can be installed only after the support block is in position.
Resource ordering edges: These record the order in which resources such as robotic arms and grippers are used, as well as modeled conflicts between actions.
Figure 1: After the support block is knocked askew, LOGIV restores the invalidated support conditions while preserving subsequent beam operations that remain usable. Source: Fig. 1 of the paper.
Connecting VLA and WAM to Establish an Execution Loop
If Graph Engineering is responsible for organizing long-horizon tasks, who performs the low-level actions? LOGIV provides a clear division of labor. The upper layer selects subtasks based on the current state and task dependencies, converting high-level actions into natural-language instructions. The lower-level policy combines the instructions with visual observations to carry out operations, after which the upper layer checks the action effects and the conditions required by the remaining plan. The completion of one action becomes the starting point for the next round of decision-making.
The paper pairs the architecture with three execution models to test whether it can span different policy approaches.
π0.5 serves as the VLA execution model, mapping visual observations and task instructions to robot actions.
AHA-WAM and Light-WAM serve as two WAM execution models, completing the operations specified by the upper layer under their respective policy architectures.
As shown in Figure 2, LOGIV constructs an independent task organization and recovery layer on top of VLA and WAM, allowing different execution policies to join a unified planning, validation, and repair loop without being retrained into a single large model or requiring additional trainable components for the framework. The architecture has been validated on task-fine-tuned π0.5, AHA-WAM, and Light-WAM. Its dependency-checking and local-repair mechanisms can be reused across policies, while integrating new tasks requires matching the corresponding task models, perception information, and execution interfaces.
Figure 2: LOGIV sits above the underlying VLA or WAM policy and checks states, nodes, and graph dependencies before and after action execution, entering the repair process once a failure is confirmed. The human assistance shown is a direction for future evaluation; the experiments reported in the paper did not enable human assistance. Source: Fig. 3 of the paper.
In terms of implementation, LOGIV realizes the architecture shown in Figure 2 through three interconnected stages: task graph construction, online validation, and local repair.
1. Task Graph Construction: Compiling the Action Sequence into a Dependency Graph
The system first uses a predefined PDDL task model to describe action preconditions, expected effects, and available objects. Fast Downward then generates an action sequence, which is passed to the independent validation tool VAL to check action arguments, preconditions, and the final goal. Only validated plans are compiled into task graphs, explicitly identifying which conditions subsequent actions depend on and which actions provide those conditions.
2. Online Validation: Continuously Checking Actions and Support Conditions
During execution, LOGIV links field observations to the task graph through the State Gate, Node Gate, and Graph Gate. The State Gate combines visual observations, robot state, and actuator feedback to confirm the current task facts. The Node Gate checks preconditions and expected effects before and after action execution, while the Graph Gate further examines task dependencies to determine whether completed actions still provide valid support for the remaining plan. Together, these form a validation process before and after action execution, enabling the system both to determine whether the current operation has succeeded and to detect changes in conditions that affect subsequent tasks.For example, even if the robot successfully picks up a beam, the Graph Gate will still identify that the condition required for the subsequent installation has been invalidated if a previously positioned support block has shifted, and will trigger a repair rather than continue execution based solely on the successful record of the current action. For states with insufficient visual evidence that cannot yet be confirmed, the system gathers additional information by re-observing or adjusting the viewpoint. If the state remains indeterminate within the observation budget, execution is stopped to avoid mistaking an uncertain state for one that satisfies the conditions.
3. Local Repair: Restoring Necessary Conditions and Preserving a Valid Plan
When a failure is confirmed, LOGIV traces the affected dependencies along the task graph and distinguishes actions that have been affected from those that genuinely need to be replaced, preserving as much of the unfinished plan as remains usable.Taking bridge construction as an example, a displaced support block does not mean that the subsequent step of installing the crossbeam is itself problematic. The system can therefore retain the relevant actions, work backward from the final goal along the retained actions to derive the conditions that must be satisfied before execution can resume, and then generate a corresponding repair segment based on the current state.
After generating the repair segment, LOGIV merges it with the retained plan and uses VAL to check whether the complete continuation plan can reach the final goal under the symbolic model, rather than merely confirming whether the failure condition at hand has been restored. If validation fails, the system replans within the current scope based on the location of the failure or expands the range of actions that need to be replaced. Once validation passes, it rebuilds the task graph and resumes execution, thereby connecting the handling of local problems with the advancement of the complete task.
Experimental Results: Multiple Low-Level Policies Can Benefit
The research team selected 10 bimanual tasks from each of RoboTwin V2 and BiCoord, for a total of 20 tasks. Each task used 10 predefined initial states, and two settings were evaluated separately: no manually injected disturbances and predefined disturbances.
Figure 3: Experimental results for different low-level policies and online correction methods. C denotes the full-task success rate without manually injected disturbances, P denotes the full-task success rate under predefined disturbances, and R denotes the failure-condition recovery rate among valid recoverable events. All values are percentages. Source: Table I of the paper.
1. Benefits with and without disturbances, with success rates improving by as much as 28 percentage points
TAG120@@As shown in column C of Figure 3, in the setting without manually injected disturbances, integrating LOGIV into the three low-level policies improved full-task success rates on both benchmarks. The mean success rate across the three models increased on RoboTwin V2 from 71.67% to 82.33%, and on BiCoord from 42.33% to 57.67%, representing gains of 10.67 and 15.33 percentage points, respectively, when calculated from the unrounded means. This shows that LOGIV is not limited to handling external disturbances; state deviations and action errors during normal execution can also be addressed through graph validation and online repair, thereby improving full-task completion rates.When the environment actually deviates from the plan, can LOGIV help the robot continue with and complete the task? The research team fixed the disturbance type and trigger conditions for each task and injected recoverable disturbances when predefined events occurred. The results are shown in column P of Figure 3, where the success rate of π0.5 on RoboTwin V2 increased from 32% to 60%, a gain of 28 percentage points. Compared with the three adapted recovery baselines—VeriGraph-PDDL, LERa-PDDL, and VLM-RP-BT—LOGIV achieved higher perturbed-task completion rates and failure-condition recovery rates for every combination of the two benchmarks and three low-level policies. Column R of Figure 3 measures the proportion of valid recoverable events in which the failure condition was recovered within the budget. It is counted separately from the full-task success rate in column P, testing the recovery mechanism from two perspectives: whether local conditions can be repaired and whether the final goal can be completed.
TAG125@@2. Graph checking and local repair each make a contributionTAG127
Are these improvements simply the result of performing a few more checks, or did the graph structure actually play a role? The research team further decomposed the key components of the framework. In the π0.5 setting on RoboTwin V2, removing Graph Gate reduced the success rate on perturbed tasks from 60% to 48%. This indicates that focusing only on the immediate action can miss dependency failures that affect subsequent execution. Replacing local repair with replanning all remaining actions increased the average number of valid completed actions that were re-executed from 0.2 to 1.6, while the success rate on perturbed tasks fell to 54%.
TAG130@@Doing more rework does not necessarily lead to better task completion. These results support LOGIV’s design choice: first determine what the subsequent task depends on, and then decide what should be repaired.TAG132Figure 4: Ablation results for graph dependency checking, local repair, and plan validation. Full denotes the complete framework, -Graph denotes the removal of graph checking, and -Local denotes replacing local repair with replanning all remaining actions. Source: Fig. 5 of the paper.
Moving to Real Robots: Putting the Execution Loop to the Test in the Physical World
The research team also tested tasks such as tomato grasping, dual-arm block stacking, and network cable plugging on the Astribot S1 dual-arm robot and a platform equipped with two AgileX Piper robotic arms. The results demonstrate that LOGIV is not only effective in simulation but also performs well in real-world deployment scenarios.
First, let’s watch a real-world demonstration of dual-arm block stacking.
Block stacking presents the same challenge as the earlier bridge-building example. A subsequent reaching motion may knock already positioned blocks out of alignment, causing the support conditions needed for the next step to become invalid. After LOGIV detects such changes, it repairs the relevant conditions and preserves the work that remains valid.
Figure 5: Comparison of successful trial counts in real-robot tasks. Each task was tested 10 times under each configuration, for a total of 30 trials per configuration, with no manually injected disturbances. Data are from Table II of the paper.
The overall success rate increased from 40.0% to 56.7%, with improvements observed across all three tasks. Deviations in real-world execution, ranging from empty grasps and premature releases to disrupted block support conditions, provided test scenarios for this graph validation and repair mechanism.
Conclusion: What Kind of Execution System Do Robots Need?
As the action capabilities of VLAs and WAMs continue to improve, Agentic Robot research faces an unavoidable question that urgently needs to be answered: How can these capabilities be combined into a complete task that can continue to make progress in a constantly changing environment? LOGIV advances Graph Engineering from task representation to online execution. LOGIV uses a task graph to record the conditions required at each step and checks during execution whether those conditions still hold. When it detects a problem, the system identifies what needs to be repaired, preserves the parts of the plan that can still be used, and resumes execution after the repairs. This reduces unnecessary rework and helps robots use existing action models to complete long-horizon tasks more reliably.
Robots need models that are better at performing actions, as well as systems that can carry on with the task despite changing conditions. LOGIV is turning the latter into a form of graph engineering that can be built, validated, and evaluated.
