The Data Frontier Is a Research Problem

Over the past several years, as LLMs have improved in capability, the industry has a much clearer understanding of the major data and training axes that drive model improvement. The exact recipe continues to evolve, but the underlying modalities, data structure, and scaling mechanisms are relatively well understood.

Robotics and voice, however, remain far less standardized and are becoming increasingly intertwined. Voice will be a key interface between people and robots, while narration can provide language grounding for egocentric VLA data. Currently, there is no settled answer for the ideal data composition nor what specific methodologies produce the most generalizable models for these modalities. Therefore, it is an incredible competitive advantage to not only collect large amounts of data faster than everyone else, but to define what data should exist in the first place.

If the right data has not yet been determined, then data collection cannot begin with a fixed specification. It has to be discovered through iteration. The most effective data work happens when the people building the models and the people building the data operate within the same feedback loop. Model researchers understand which failures matter for the model, but they may not know what those failures imply operationally at the collection layer. A data company understands how the collection process can be changed, but may not know how those changes will affect downstream model behavior. Neither side can efficiently optimize the system in isolation. The value comes thus from continuously connecting model behavior back to the physical process that produced the data.

Robotics already has a precedent for this kind of feedback loop. In standard imitation learning, a policy is trained on expert demonstrations, but once deployed, even small mistakes can push it into states that were never represented in the original training data. DAgger (Dataset Aggregation) addresses this by repeatedly rolling out the policy, having an expert provide the correct actions for the states the policy encounters, adding those examples to the training set, and retraining the policy. The model’s own behavior therefore determines the distribution from which new data is collected. The opportunity is to extend this principle from determining which examples a model needs next to determining how the next collection should be designed in the first place.^[1]

Frontier model labs themselves are still experimenting on which directions are worth scaling. Their research, however, is focused on the models themselves: architectures, training objectives, evaluations, failure modes, and emerging capabilities. But data is a much more fluid problem. Every new data hypothesis creates a second research problem at the collection layer: what hardware to use, how tasks should be structured, which environments matter, what demographic and acoustic diversity, and how quality should be measured. Model labs should not have to build an entirely new experimentation layer for every new hypothesis.

The data company, in contrast, operates closest to the collection process. We see how people behave under different protocols, how hardware performs outside a controlled lab, and which specifications break down in practice. A small change in camera positioning can alter the visual distribution a robotics model learns from; a slight shift in microphone placement can change the acoustic cues a voice model learns to recognize and respond to. These details may appear trivial in a specification, but across thousands of hours of collection they can materially shape the resulting dataset and ultimately the behavior of the model trained on it.

UMI (Universal Manipulation Interface) provides a concrete example of how consequential these collection decisions can be. Robot learning from human demonstrations is difficult partly because the demonstration interface has to capture both what the human sees and the actions the robot should later reproduce. Existing handheld systems had limitations in visual coverage, action recovery, and transfer to robot policies. Rather than simply collecting more demonstrations through those interfaces, the UMI researchers redesigned the collection system around those limitations. Visual coverage, action recovery, sensing, and representation became part of the research problem because they determined what information was ultimately available to the learned policy. The collection system itself therefore became part of the research contribution.^[2]

A similar dynamic appears in voice. Speech-recognition models are typically strongest on speech that resembles the distributions represented in their training data, which can leave them substantially less capable on atypical speech. Google’s Project Euphonia began from this failure: standard speech-recognition systems performed poorly for speakers with conditions that altered their speech. Researchers responded by collecting targeted speech from those populations, fine-tuning the models, and analyzing the resulting phoneme-level errors to understand where the existing data remained insufficient and how future collection could be improved. As the project expanded, decisions around what speech to collect and how to structure the dataset became part of the research process itself.^[3][4]

In examples like UMI and Euphonia, this experimentation has largely been carried out inside the research organization itself. A data company deeply integrated with the model team could make that process substantially faster: translating new hypotheses into collection experiments, testing different hardware and protocols in parallel, and expanding the approaches that prove useful. Instead of rebuilding the operational layer around every new research question, the lab could continuously iterate against an existing collection infrastructure.

Once that experimentation layer exists, its value compounds. Methodologies can be compared, hardware and task design changed, new modalities introduced, and whatever proves useful scaled across future collections. Because the definition of the “best data” is still evolving, the collection system has to evolve in tandem with the models it serves.

This continuous iteration is also why selling off-the-shelf multimodal data is inherently backward-looking. A dataset can only be standardized once enough buyers agree on what they need. At the frontier, however, those requirements often emerge before a market exists for them. A data company operating at the frontier cannot wait for broad demand; it has to keep pace with research and in many cases, experiment ahead of it. That requires a relationship with model teams that functions much more like a research collaboration than a transactional marketplace.

This is the role we want Datoric researchers and engineers to play: understanding why a dataset is being collected, how it will be used, what capability it is intended to unlock, and what assumptions need to be tested before a collection is expanded. That is fundamentally different from treating data as something ordered from a catalog.

Of course, volume still matters. The frontier robotics and voice models consume enormous quantities of data, and building the infrastructure required to collect high-quality data reliably across many environments and participants is difficult. But scale is only useful if it is pointed in the right direction. A massive dataset built around the wrong abstraction can have surprisingly little value, while a smaller dataset designed around a specific model limitation can produce a far greater improvement. The research process determines what is worth scaling; the collection infrastructure determines how quickly it can be scaled.

The next frontier of data will be shaped through a continuous process of research, experimentation, and scale. Model behavior will reveal new gaps, those gaps will produce new collection hypotheses, and the resulting data will shape the next generation of models.

Datoric is being built to operate inside that loop: to understand where the frontier is moving, develop the data needed to move it further, and build the infrastructure to produce that data at scale.