You tell a robot, "Pick up the cup and put it on the shelf." It has to see the scene through a camera, take in a spoken instruction, and move its arm and gripper. A model that takes in vision and language and turns them into action is called a VLA—the name is just those three words strung together.
These models have a failure you see again and again. The robot fails to grab the cup. And yet it heads for the shelf anyway, empty gripper in hand. With nothing in its grasp, it goes through the motion of setting it down. It never looked at how the scene actually changed—it just rewound and replayed the sequence of motions it saw during training.
VLA-Δ sets up a different learning objective. Instead of attaching an observation directly to an action, it teaches the difference between the current state and the next one—what has to change, and how. The Δ (delta) in the title points to this quantity of change.
What this work is after is manipulation performance. It learns state changes to drive up task success rates. Demonstrating a "recovery" ability—noticing a failure on its own and undoing it—is out of scope. That distinction follows you through the whole results section, so it's worth stating up front.
The design of a VLA is simple. It takes a video and an instruction like "open the drawer," borrows the knowledge of a pre-trained vision-language model (VLM, a model trained to understand images and text together), and turns it into joint motions. Benchmark scores are already high. The problem is how it goes wrong. It closes the gripper before reaching the target; it fails to grab something and still moves to where it would set it down. In both cases, it can't read how the scene is changing.
This is where the learning objective makes the difference. Most VLAs learn to match the pair "this observation goes with this action." They line up an observation with a demonstrated action directly, but never learn the physical change in state that's supposed to happen in between. So they cling to specific combinations of scene and action (overfitting), and the moment the scene is nudged even slightly, they fall apart. Instead of matching pairs, VLA-Δ learns to predict "what changes from now to next."
It's not that nobody has tackled the middle part. The paper sorts prior work into three strands.
Existing approaches teach either high-level task semantics or the future's outward appearance. What they rarely teach is how the object's pose, the spatial relations, and the contact between robot and object change from now to next—the physical state transition itself. And it's precisely this change that actually dictates the action the robot should take. That's the gap VLA-Δ digs into.
At the heart of VLA-Δ are Physical State Difference Queries. A query is a bundle of numbers trained to hold the change information needed to decide an action. It starts as an empty vessel, but once training is done, it holds a compressed account of "what changes from now to next."
Picture the scene of picking up a cup and setting it on a shelf. The robot observes the current frame and the gripper's state. The query, conditioned on that observation and the instruction, draws out the change information, and the action is decided by looking at that change information. Observation → change → action. The key is that one extra step—change—slots in the middle.
So what do we train the query to hold? This work has it record changes like "where the cup is now and whether the gripper has made contact" in three ways.
The three ways transcribe the same change in different languages. So what one misses, another fills in. On-screen motion tells you where the cup and hand went, but not whether the gripper actually gripped the cup—because the cup and hand can slide along together without a grip. State entries tell you whether it gripped or not, but not whether that grip is one that brings it closer to the goal. The sentence description gives you the direction of progress toward the goal, but is empty on the concrete motion in the current frame. Put all three together and the cup's position, the gripper's contact, and the progress toward the goal complement one another inside a single query.
The design has one more device. The pathway that produces the change information isn't allowed to touch the raw video and instruction directly—it's funneled so it can only go through the query. That means any information from the observation has to pass through the query once before it can feed the change description. Narrow the passage, and the signals from the three ways get pushed into the query, so the query naturally learns to hold the change.
The most important operational decision is that these three records are used only during pre-training. When fine-tuning for a task, it optimizes the single action objective alone. That means you don't have to annotate the change afresh for every task. At deployment, too, only the change-extraction and action-generation paths remain; the auxiliary objectives aren't computed. So inference cost doesn't go up. This is the spot where it sidesteps the weakness of the WAM family, which had to draw a future image every time.
Where the performance comes from is settled by the ablation study (an experiment that toggles elements on and off one at a time to measure each one's contribution). These are on the 40 LIBERO tasks.
| Configuration | LIBERO avg (%) |
|---|---|
| Dense VLM features (no pre-training) | 95.70 |
| Dense VLM features + pre-training (action only) | 95.85 |
| Difference queries only (no pre-training) | 96.25 |
| Difference queries only + pre-training (action only) | 96.45 |
| Queries + difference text | 97.20 |
| Queries + structured slots | 96.90 |
| Queries + optical flow | 97.35 |
| VLA-Δ (full) | 98.40 |
If you use the same data with action supervision only, the gain is almost nothing (95.70→95.85, 96.25→96.45). But adding the query mechanism lifts it 0.55pp over the baseline (95.70→96.25). This comparison shows that what moved performance wasn't "seeing more data" but "what you taught." The full configuration, with all three records added, is highest at 98.40%.
One line worth drawing. What the table directly shows is only this far: "adding all three records raises the success rate." The earlier claim that "each record fills in the others' blind spots" is an interpretation layered on top of those numbers. Reading the two as a single proof overstates what the numbers can carry.
Evaluation ran on both a simulator and a real robot, with task success rate as the main metric. Here are just the headline results.
Fundamental execution (LIBERO). LIBERO looks at basic manipulation across four suites (Spatial, Object, Goal, Long). VLA-Δ (2B) averaged 98.4%, ahead of every comparison method in the table. That's a number earned with a smaller footprint than 7B-class models like openVLA-OFT (97.1%).
When you shake the environment (LIBERO-Plus, RoboTwin 2.0). LIBERO-Plus applies four perturbations—language, lighting, background, layout—to the same tasks, testing situations unseen in training. It held high success rates across all four, and under language perturbation it hit 89.0% against the comparison's 82.6%, a 6.4pp edge (this comparison is the number for the single language condition). RoboTwin 2.0 randomizes the scene. At 90.06% on the clean setting and 89.74% on the randomized one, it beat the comparison methods on both. What's worth noting is the size of the drop. Going from clean to randomized, the average fall was just 0.32pp. Over the same transition, the strongest baseline, ZR-0, fell 0.72pp and Motus 1.50pp. This squares with the direction of explicitly teaching state change, but that correspondence is the authors' interpretation—not a causal link beyond a correlation between task properties and scores.
A real robot (AgileX PiPER). On an AgileX PiPER 6-DoF dual-arm robot, five tasks (obstacle avoidance, long-horizon execution, precise manipulation, spatial reasoning, generalization to environment change) were each run 40 times, 200 runs in all. It averaged 68.0%, 5.5% higher than π0.5, the comparison model shown in green. It was highest at obstacle avoidance with 42.5%, which the authors connect to the "obstacles to avoid and relations to keep" part written into the change description.
A note on what success rate can't measure, too. Success rate holds only the binary outcome of "did it finish." Whether the motion was smooth, whether the trajectory left a safety margin—none of that gets in. The gap between simulator and real-robot success rates also remains, which is exactly why the authors ran 200 separate trials on the real robot. "The success rate went up" is not the same as "the robot noticed a failure and recovered." The caveat set out earlier holds here too.
It's a robotics paper, but there's something to carry over to those of us running work agents, too. The design question this work hands us is this: can we specify a change in state, rather than a behavior, in work tasks as well?
Say an ONTLE AI PM handles the recurring job of restocking for a small business. Every day it checks inventory, builds a purchase order for items below threshold, enters it into the supplier portal, and updates the internal ledger. The common way to build this is to learn an input→behavior mapping—"when this screen shows up, click this button"—from demonstrations.
The problem is when a purchase order gets kicked back partway through. The agent can't read the rejection screen and barrels straight into the memorized next step. It counts a rejected order as received and updates the ledger. It slipped at the very same spot as the robot that fails to grab something and heads for the shelf anyway.
The principle to borrow from this paper is one thing. Hold the "expected state transition" between step and step as an explicit variable, and watch whether that transition actually happened—not the screen.
From here on is a separate operational design ONTLE proposes, not something the paper implemented. For a purchase-order step, you'd write down the expected state first. "The target item flips from not-ordered to order-received, a receipt number is issued, and supplier confirmation goes into pending." Before moving to the next step, you check whether this transition actually occurred. If it's off, you don't barrel ahead—you stop or back out. And you bring along the paper's cost principle too: push the heavy state learning into pre-training and keep execution light. Forcing long-winded reasoning at every step during execution is slow and expensive. That said, let me restate that in-execution checking and recovery are an ONTLE-side design proposal, beyond the performance gains the paper covered.
This design is measurable. You deliberately mix in screens where the order was kicked back, and compare two numbers—before and after adding the state-check device. The rate of incorrect ledger updates, and the time to process one item. If the rate drops and the time doesn't balloon, this connection stands on measurement, not on principle.
Structured Transition Slots split task-relevant state variables into nine categories, each with its own prediction target: task progress, task stage, goal position, gripper position, motion/relative displacement, interactable position, gripper state transition, contact transition, and obstacle risk. Each category has a lightweight prediction head that reads the corresponding query and produces a value.
Dense Optical Flow teaches the 2D motion between the current and next observation, from the same viewpoint, pixel by pixel. The loss uses both the mean error over all pixels and the error on the "motion pixels" whose movement exceeds a threshold.
Future-State Difference Text narrates in natural language the task progress, spatial change, contact transition, and physical constraints to be kept between the present and the future, and is trained with the VLM's native next-token prediction (autoregressive) objective.
Action generation follows the GR00T N1 architecture. The backbone is Qwen3-VL-2B-Instruct, and the action expert is a 9-layer Diffusion Transformer. The action expert takes the change information via cross-attention, combines it with separately encoded robot proprioception, and turns noise into continuous actions via flow matching.
The nine slots use seven fixed query groups (task progress and stage share G12; gripper state and contact transition share G78). Spread the internal state of a query that received structured supervision onto two dimensions with t-SNE, and it forms distinct clusters by group; without supervision, it scatters. That's a sign the design that handed queries their own roles actually works.
The pre-training data is about 484 hours, 24 million frames, gathered from DROID, MolmoAct, and RH20T. The VLM started from ZR-0 base weights. The state-change annotations weren't hand-labeled one by one. All sources were unified into the LeRobot v3 trajectory format → Qwen3.8 segmented the video into manipulation stages (approach, align, grasp, etc.) to generate keyframes and semantic labels → SAM 3 produced bounding boxes and segmentation masks for the target object, gripper, and obstacles → UniDepth V2 estimated depth → MegaFlow computed offline optical flow. Quality control runs automated checks (format errors, temporal misalignment, coordinate anomalies, object-identity mismatches, depth anomalies); annotations that are complex or in conflict are reviewed field by field by GPT-5.6 against the visual evidence; and a stratified-sample manual audit sits at the end. It's automated, but not a structure that lets things through without checking. This heavy annotation was pushed into pre-training all at once, so it doesn't have to be re-labeled per task.