Hebbian Robotics open-sourced HFlow to clean up robot-training data

Why it matters

Robot models depend on large, messy multimodal datasets. Hebbian Robotics is betting that quality checks, provenance and reproducibility can become a shared software layer rather than bespoke internal work.

On August 19, Brandon Ong and Kingston Kuan announced HFlow, an open-source SDK for processing and checking the multimodal data used to train robots, through their 2026 startup, Hebbian Robotics.

Ong and Kuan arrived at the problem from opposite ends of the robotics data stack. Y Combinator's profile of Hebbian Robotics says Ong built two-arm industrial cleaning robots at LionsBot International, worked on AI for low-resource languages and previously co-founded Gigit AI. Kuan worked on high-throughput systems at Jane Street and the video platform at Verkada. Hebbian Robotics is a two-person startup in YC's Summer 2026 batch.

Their experience points to a less visible constraint on robot development. A training corpus can contain synchronized video, actions, sensor states, timestamps and metadata collected across different robots and recording systems. Before any model sees that material, engineers have to find frozen cameras, missing streams, timing drift, duplicate recordings and other defects that can poison a training run.

Hebbian's August 19 post describes HFlow as open-source data-quality infrastructure for Physical AI. The hflow package was released on PyPI on August 20.

The founders chose infrastructure first

HFlow gives robotics engineers a way to keep their existing transformations and quality checks as Python functions. Hebbian Robotics supplies the machinery around those functions: orchestration, durable execution, storage, versioning, provenance and dataset curation.

The SDK accepts episodes stored in MCAP, a container suited to synchronized video and time-series streams. HFlow can process data collected from teleoperated robots, autonomous policies or human-worn cameras once the episode has been represented in the supported format. The HFlow repository documents generated Airflow DAGs for scheduled runs, a Parquet catalog for episode metadata and quality evidence, and DuckDB SQL for querying and curation.

Each processed episode receives version information identifying the schema, pipeline and tools that produced it. That detail matters when a robotics group changes a quality check or discovers a flawed transformation after processing a large corpus. Engineers can trace affected outputs and reproduce a particular dataset rather than treating every processed directory as a final, unexplained artifact.

Hebbian Robotics has deliberately separated measurements from policy. According to the project's architecture documentation, a check can record black-frame percentages, missing intervals or other evidence, while the user decides later which thresholds qualify an episode for a training dataset. Two projects can therefore apply different quality standards without decoding and processing the original media again.

The current repository is labeled pre-v1. The architecture documentation says HFlow ends at processed episodes and a curated manifest, while model training remains outside its scope.

That boundary keeps the initial product focused. Hebbian Robotics now has to persuade robotics teams to adopt a common pipeline layer even when their checks, formats and training systems differ.

Open source as the entry point

Ong wrote that conversations with data teams pushed Hebbian Robotics toward open source. The reasoning is practical. Camera failures, unusual sensor behavior and collection mistakes tend to recur across robotics projects. A check contributed for one deployment can save another engineering group from rediscovering the same defect.

Open source also gives a two-person startup a way into robotics organizations that may resist sending valuable training data to a new vendor. HFlow can run in infrastructure controlled by the user, and its documented components include MCAP, Airflow, Parquet and DuckDB. Existing processing code stays in the user's environment rather than being rewritten for a proprietary system.

That design places HFlow alongside a growing set of tools around robot data, including visualization and logging systems such as Foxglove and Rerun and dataset tooling around Hugging Face's LeRobot. Encord also sells enterprise tooling for robotics and embodied-AI data. Hebbian Robotics is concentrating on the middle of the workflow: repeatable transformations, quality evidence, provenance and the production of version-pinned datasets.

Hebbian Robotics has already built Pareto, which it describes as a robotics data curation platform. HFlow turns parts of that broader data-quality thesis into an SDK that engineers can inspect, run and extend.

Infrastructure for a broader robotics ambition

Kuan has described a broader mission for Hebbian Robotics. In a post announcing the YC batch, he wrote that Ong and he want robots to work with expert field crews in remote sites, subsea environments, orbit and other locations that are difficult for people to reach safely.

HFlow is several layers removed from building those machines. It gives the founders an immediate product around a problem they have already encountered, while exposing Hebbian Robotics to the data practices of the labs and collection businesses training physical systems. The pipeline can show the company what robots record, how field operations fail and which data-quality problems recur across teams.

Y Combinator lists Hebbian Robotics in its Summer 2026 batch. Hebbian Robotics also says it has angels from Oracle, Google DeepMind and OpenAI without naming the individuals.

For Ong and Kuan, the next milestone is adoption. HFlow has to prove that robotics engineers want a shared infrastructure layer badly enough to replace their current tools. The founders have started with plumbing because robots cannot learn reliably from corrupted or poorly documented data.