There were 164 Vision-Language-Action (VLA) model submissions at ICLR 2026. One year earlier, there were nine. The year before that, one.
The VLA explosion is real. Physical Intelligence's π0 through π*0.6 evolution. Figure AI's Helix. NVIDIA's GR00T N1.6. Google's Gemini Robotics. Stanford's OpenVLA. Hugging Face's SmolVLA. The architecture papers keep coming, each claiming incremental improvements on manipulation benchmarks, each accompanied by impressive demo videos of robots folding laundry.
I've been reading these papers obsessively for the past year. And something keeps nagging at me.
Nobody is talking about the data.
Not really. Physical Intelligence has published 13 deeply technical blog posts detailing flow matching, action tokenization, knowledge insulation, real-time chunking, embodied memory systems, and reinforcement learning methodologies. Zero posts discuss how training data gets labeled, curated, or quality-controlled. They mention "10,000+ hours of robot data" and reference partner data effects, but the data infrastructure itself remains a black box.
This pattern repeats across the industry. Figure AI's Helix paper mentions VLM-generated hindsight labels in passing. Skild AI talks about needing "trillions of examples" without addressing how those examples get validated. NVIDIA generates 780,000 synthetic motion trajectories in 11 hours, but who checks whether those trajectories are physically plausible?
I've seen this pattern before. At Autopilot, we had more driving data than anyone on the planet, and still, the breakthroughs came from data quality improvements, not architectural innovations. The teams that won weren't the ones with the most data or the cleverest models. They were the ones with the cleanest labels, the most rigorous quality assurance, and the infrastructure to trace any model behavior back to its training source.
The VLA field is about to learn this lesson the hard way. Beyond a capability threshold, data quality dominates architecture. The teams that treat data infrastructure as a first-class engineering problem will ship production systems; the teams that treat it as an afterthought will stay stuck in demo mode.
The gains are coming from data, not architecture
The discourse around VLAs is almost entirely model-centric. Which vision encoder? PaliGemma or SigLIP or DinoV2? Which action head? Flow matching or diffusion or autoregressive? Which backbone scale? 3B parameters or 7B or 55B? These questions matter. But they're not the questions that will separate production-grade systems from demo-grade ones.
Consider Physical Intelligence's own results. When they published π0.5, their "open-world generalization" model, the headline capability was handling novel objects and environments without task-specific fine-tuning. Buried in the technical details was something more revealing: including heterogeneous pre-training data from partners like Weave Robotics and Ultra yielded a 42% improvement in grasp success rate and a 50% reduction in human intervention during deployment. That's not an architecture improvement. That's a data improvement.
OpenVLA makes the same point against scale. RT-2-X is 55B parameters, nearly 8x larger than OpenVLA's 7B, yet OpenVLA outperforms it by 16.5 percentage points on standard manipulation benchmarks. The OpenVLA team attributes the gap to training data curation and quality, not architectural superiority. SmolVLA pushes further: at 450M parameters, it matches models 10x its size through aggressive data curation and efficient training recipes.
Three results, one lesson. Yet conference papers still compete on architectural novelty, funding announcements still highlight parameter counts and compute budgets, and the data infrastructure that actually determines model performance stays invisible.
VLA training data is nothing like internet data
A VLA training example isn't a static image with a label. It's a temporal sequence, typically recorded at 30–50Hz for camera observations, 100–1000Hz for proprioceptive state, and potentially higher for force/torque sensing, that must be precisely synchronized across modalities. A single manipulation trajectory might include RGB images from base and wrist cameras, depth maps, 7-DoF joint positions and velocities, gripper state, end-effector pose, and in some cases force feedback from tactile sensors.
All of this must be temporally aligned. A 50-millisecond misalignment between camera frames and proprioceptive state can corrupt the action labels entirely, because the model is learning the mapping from observation to action at a specific moment in time. The label for "what action was the robot taking when it saw this image" becomes meaningless if the image and action are from different moments.
The labels themselves are stranger still. Unlike image classification, where the label is a discrete category ("cat" or "dog"), VLA annotations are continuous trajectories in action space. A bounding box either contains an object or it doesn't. A manipulation trajectory exists on a spectrum of quality: some grasps are more stable, some motions more efficient, some recoveries from perturbation more robust. Capturing that richness requires labeling frameworks the field hasn't standardized.
This is a data infrastructure problem, not a modeling problem. And most teams are solving it with duct tape.
Diversity beats volume
The prevailing narrative in Physical AI is that we need more data. Skild AI's answer is scale. NVIDIA's simulation-first approach generates synthetic trajectories at massive volume. The assumption is that scaling laws (more data leads to better models) apply to robotics just as they did to language.
The evidence points the other way. Research from the robotics learning community consistently shows that data diversity matters more than raw volume. One study found that 32 distinct environments with 50 demonstrations each achieved 90% success on novel test settings, while 1,600 demonstrations from a single environment achieved only 45%. The marginal value of another demonstration in the same environment drops rapidly after a threshold.
If diversity dominates volume, the goal isn't to record 100,000 hours of manipulation data: it's to record data from 10,000 distinct environments. The collection strategy, the annotation ontology, and the curation pipeline all need to optimize for diversity, not just scale.
There's a second complication: expert demonstrator variability. Counterintuitively, multiple human demonstrators with different styles can hurt model performance. The reason is "velocity multimodality": different experts perform the same task at different speeds, creating a multimodal distribution in action space that confounds learning. One analysis found that debiasing for demonstrator style was equivalent to increasing dataset size by 2.5x.
Naive scaling won't work. Throwing more teleoperation hours at the problem without addressing diversity, demonstrator consistency, and quality assurance hits diminishing returns quickly. Yet most teams still operate as if more data is always better.
The six-tool stitching problem
Walk into any robotics lab and ask how they manage training data. You'll hear some version of the same answer: a patchwork of open-source tools, cloud storage, and custom scripts held together with hope.
Data gets recorded in ROS bags or MCAP files on the robot, uploaded to S3 or GCS, visualized in Foxglove or Rerun, annotated in Encord or Scale AI or a custom internal tool, versioned in DVC or Weights & Biases Artifacts or timestamped folders, quality-checked in spreadsheets, and exported through custom conversion scripts.
Each transition between tools loses information. Temporal alignment verified during recording isn't preserved through format conversion. Annotation schema evolved in the labeling tool aren't reflected in the training pipeline. Version control doesn't capture the relationship between raw sensor data, processed observations, and final labels. When a model fails on a specific edge case, tracing back to the source data requires archaeology.
Adrian Macneil, who led data infrastructure at Cruise before founding Foxglove, described the problem directly: companies like Tesla and Waymo have "hundreds of people building this tooling internally." Most teams can't afford that, and no integrated solution exists, so data quality becomes a function of engineering bandwidth. Teams that can build robust ingestion, annotation, quality assurance, and export pipelines get better training data. Teams that can't end up with data that's technically sufficient but subtly corrupted (misaligned timestamps, inconsistent annotations, undocumented preprocessing steps) in ways that only surface as mysterious model failures months later.
Annotation has no standard primitives
Computer vision annotation is mature. Bounding boxes, segmentation masks, keypoint detection, instance segmentation: the primitives are well-understood, the tooling is sophisticated, and inter-annotator agreement metrics are standardized. Robotics annotation is none of these things.
Annotating a manipulation trajectory for VLA training means identifying task phases (approach, grasp, lift, transport, place) and their transition points. Characterizing grasp quality: is this a stable power grasp, a precision pinch, a fingertip grip? Labeling contact events: when did the gripper first touch the object, when was full contact achieved, when did slip begin? Classifying force profiles where force/torque sensing is available: is this a gentle grasp suitable for soft objects, or a firm grasp for rigid ones?
None of these have standardized taxonomies. Different research groups use different ontologies. The Open X-Embodiment dataset uses RLDS format, which captures observation-action pairs but provides no schema for quality labels. Figure AI's auto-labeling uses VLM-generated hindsight annotations, but these capture what happened rather than how well it happened.
Physical Intelligence's RECAP methodology shows how deep the requirements go. RECAP trains policies not just on demonstrations, but on correction data (trajectories where a human coach intervened to fix a mistake) and autonomous experience collected during deployment. Each category requires different labeling: demonstrations need task phase annotations, corrections need identification of what went wrong and what the fix was, and autonomous experience needs success/failure labels plus advantage estimation, which takes either human judgment (expensive and subjective) or a separate value model.
The lack of standardization bites at every level. Datasets can't be combined because their schemas differ. Quality metrics can't be compared. Transfer learning trips over ontology mismatches. And every team reinvents the same annotation primitives, poorly. None of this makes for exciting research papers. All of it determines whether VLA systems reach production.
Autonomous driving already ran this experiment
We had massive amounts of data, eventually billions of miles, and architectures that kept improving. The inflection points still weren't new models. They were improvements to labeling consistency, reductions in annotation latency, better tools for identifying and debugging edge cases, and the ability to trace a specific model failure back to its training data source and understand exactly what went wrong.
The winning teams eventually rebuilt their entire data infrastructure stacks. Not incremental improvements: a complete reimagination of how data was labeled, curated, and served to training pipelines.
The VLA field is earlier in this journey. The improvised infrastructure holds for now because the datasets are still small enough to manage manually. But the path to production (robots in factories, warehouses, homes) runs straight through the data quality problem.
The coming reckoning
Here's what I expect over the next 18 months.
Architectural innovation continues, but the returns diminish: slightly better action tokenization, slightly more efficient inference, slightly better zero-shot transfer, and no breakthrough that moves the fundamental capability frontier.
Meanwhile, teams start hitting data quality walls. Models that perform brilliantly in the lab fail mysteriously in deployment. Debug cycles lengthen as engineers struggle to trace failures back to data sources. Annotation inconsistencies compound across dataset versions. The duct tape strains under production load.
The companies that come through this transition will be the ones that treated data infrastructure as the foundation that model development depends on, not as an afterthought to it. Physical Intelligence is clearly thinking this way: RECAP requires infrastructure that handles demonstrations, corrections, and autonomous experience as distinct labeled categories, and their partner strategy (Weave Robotics, Ultra, others) requires merging heterogeneous data sources with different formats and ontologies. But they haven't talked about it publicly, which means the rest of the field is trying to catch up without a roadmap.
The robotics industry figured out how to build impressive models. Now it needs the data infrastructure those models require, and no architecture paper will substitute for it. We watched this play out in autonomous driving. VLA will be no different.
