Hebbian Robotics open-sources HFlow, an SDK for multimodal robotics data pipelines

What launched

Hebbian Robotics, a startup from the Y Combinator Summer 2026 batch, has open-sourced HFlow, an SDK for building scalable multimodal data pipelines in robotics and physical AI. The company announced the project in a launch post on Hacker News and published the code on GitHub. The project sits at version 0.2.0 and is described as pre-v1, though Hebbian says the core lifecycle works end to end and is ready to try locally.

The bottleneck it targets

According to the launch post, Hebbian sees data processing as a major bottleneck in robotics. A corpus typically mixes video, robot state, actions, timestamps and metadata from several recording systems. Teams tend to feel the pain first in quality control: working out whether a camera froze, streams drifted out of sync, required topics disappeared, or duplicate recordings entered the dataset. As the corpus grows, fragmented scripts make it hard to know what ran, audit results or reproduce a dataset. HFlow's stated goal is to make data tooling and practices that are usually built inside large robotics teams accessible to teams of any size.

How HFlow works

Data moves through a four-stage lifecycle: collection into a landing bucket, ingestion as an Airflow DAG with transforms, a quality gate and enrichment, curation via SQL over an episode catalog, and delivery as curated MCAP plus a manifest that can be converted for training.

The user's processing code stays theirs. Transformations, checks, labels and enrichments are plain Python functions in the user's own environment, and existing code plugs in through small adapters rather than being rewritten for a proprietary framework. HFlow handles the orchestration, storage, versioning and curation around those steps. Execution runs in-process during development and generates Airflow 3 DAGs for scheduled runs.

MCAP is the v1 input and output boundary, chosen because it efficiently stores and serves synchronized video, state and other time-series streams. ROS 2 records the format natively and tools like Foxglove and Rerun open it directly. Hebbian says episodes are written with in-band H.264 using a GOP length matched to read patterns, plus topic-group chunking so camera and state streams never share a chunk, meaning a training sample costs one read per group rather than one per topic. Input can come from human-worn cameras, teleoperated robots, autonomous policies or other collection systems, provided the data is represented as a supported MCAP episode. An importer also accepts LeRobot Dataset v3 repositories, resolving a branch reference to an immutable commit that is recorded as provenance.

Traceability is a recurring theme. Each processed episode carries metadata recording the schema, pipeline and tool versions that produced it, along with its source URI when available. The pipeline renders as a graph through Airflow, so teams can see how stages connect and monitor task status, logs, retries and reruns.

Quality checks produce reusable evidence rather than verdicts. Accessors surface the inputs existing code expects, such as numpy arrays, MP4 paths or JPEG frames, and results land in a Parquet catalog as queryable measurements. That means different datasets can apply different thresholds without reprocessing the media, and DuckDB can answer corpus-wide questions and build manifests without opening the underlying MCAP files.

Hosting and roadmap

The open-source deployment is intended to be easy to own: a single-tenant workspace with the bundled Docker Compose runtime, or a generated DAG bundle deployed into an Airflow 3 environment the team already operates. There are no user accounts, RBAC or multi-tenant control plane. Hebbian has kept the data plane separate from control-plane concerns so the same engine could run as multiple isolated workspaces behind an external control plane. That is the stated path to a future hosted version, though the company notes the hosted control plane is not implemented in the repository and is not a pre-v1 commitment; a waitlist is open for hosted interest.

One caveat worth noting: earlier 0.1.x releases under the same PyPI name belonged to an unrelated, inactive project before the name was transferred.

Why it matters

As more teams train robot policies on large multimodal corpora, the unglamorous plumbing around that data, including versioning, quality evidence and provenance, increasingly decides whether results can be trusted and reproduced. HFlow treats these as first-class artifacts instead of ad-hoc scripts, and by betting on open formats and tools such as MCAP, Parquet, DuckDB and Airflow, it keeps switching costs low, which would also make a future hosted product easier to adopt. The pre-v1 status means prospective users should check the open issues, but the quickstart runs without Docker or Airflow, synthesizes its own test episode when no recording is supplied, and contributing requires no robot hardware, so the barrier to evaluation is deliberately low.