Rerun data model

The hard part of ingesting a dataset is the modeling decision, not the API call. Get the model right and any mechanism works; get it wrong and queries, views, and training all break. This skill is just the decisions. For mechanism details see rerun-chunk-processing (pipeline mechanics) and the importer skills it routes to: rerun-mcap,rerun-urdf,rerun-parquet, rerun-mp4, rerun-lerobot. For exact signatures, the docs at rerun.io/docs/concepts/logging-and-ingestion.

Before writing conversion code, fill in the mapping table below. It is the design, and a human can review it in seconds.

Pick the mechanism before you model the bytes

Modeling decides what each datum becomes; this decides how it gets there, and the default is a reader + lenses, not hand-built chunks:

• Does a reader exist for this source? MCAP→McapReader, URDF→UrdfTree, parquet→ParquetReader, HDF5→Hdf5Reader, RRD→RrdReader, LeRobot dir→log_file_from_path. Yes → reader.stream() + lenses; the reader produces the chunks, you do not.
• No, and it is genuine external metadata (JSON calibration, offsets) or a specific custom use case that can't be covered by a generic reader**→** Chunk.from_columns.
• Otherwise: consider if you are about to hand-build something a reader or lens should produce and ask for clarification.

For MCAP specifically: a Foxglove- or ROS-decodable file emits archetypes like Transform3D, Pinhole, and VideoStream for certain supported message schemas ready-made, pass those through, never re-derive them; only custom protobuf signal topics need lenses. The full decision tree and the anti-pattern list are in rerun-chunk-processing.

The model

Dataset → Segment → Layer → Recording → Entity → Component → Chunk