Start with where the compute goes. Decoding synchronized video and time-series streams is the expensive part of a robot data pipeline, and Hebbian's architecture documentation says the reject decision does not live there: a check records evidence such as black-frame percentage or missing intervals, and the user later decides which thresholds qualify an episode for a training set [9]. The payoff is that two projects can hold different quality bars against the same processed episodes without decoding and processing the original media again [10].
The discipline that buys is on the check author. Record a number and the next team runs a query; record a boolean and the next team decodes the video again [9][10]. That is a convention, not an enforcement mechanism, and conventions are the part of a pre-v1 SDK most likely to move [11].
The documented stack names four components: MCAP going in, generated Airflow DAGs for scheduled runs, a Parquet catalog for episode metadata and quality evidence, DuckDB SQL over that catalog for querying and curation [7][13]. Count them and what Hebbian supplies on top is glue rather than a storage engine: orchestration, durable execution, versioning, provenance, curation [2]. That shapes the migration bill. Your transformations move as-is because they stay Python functions [5], and the thing you inherit is a catalog layout and a scheduler.
If your recordings sit in a vendor's proprietary log, the converter is the first task, and it is yours. HFlow will take teleoperated, autonomous-policy or head-camera episodes only once they are represented in the supported format [6].
The open-source route has a stated reason and an unstated one. Ong wrote that conversations with data teams pushed the project open, on the logic that camera failures, unusual sensor behaviour and collection mistakes recur across robotics projects, so a check contributed for one deployment saves another group the rediscovery [12]. The commercial reason is that a two-person startup [3] asking a robotics group to ship its training corpus to a new vendor gets a short meeting. HFlow instead runs in infrastructure the user controls, with existing processing code staying in the user's environment [13].
The founders' backgrounds line up with the two failure classes. Y Combinator's profile has Kuan on high-throughput systems at Jane Street and on Verkada's video platform, and Ong building two-arm industrial cleaning robots at LionsBot International [15][14]. Timing drift across recording systems and dropped or frozen video streams are the defects that poison a run before any model sees the data [4].
What remains is adoption, and Hebbian's own framing concedes the difficulty: robotics teams have to accept a common pipeline layer even when their checks, formats and training systems differ [17]. The project positions itself in the middle of the workflow, next to visualization and logging tools such as Foxglove and Rerun, dataset tooling around Hugging Face's LeRobot, and Encord's enterprise offering for embodied-AI data [16]. That middle is genuinely the part most teams write badly, because it is unglamorous and never ships a demo.
In my context I would run HFlow over one corpus, keep the existing scripts alive for a quarter, and diff the manifests. The measurement-versus-policy split is worth the trial on its own; if it holds, the same decode serves two labs with different standards, which is the only claim here that changes an actual budget line [10].
