Explanation

This section explains how infrastore is put together and why. It is understanding-oriented: read it to build a mental model, not to accomplish a specific task. For the calls that do the work see the Developer Guides; for exhaustive listings see the Reference.

• Architecture — The crates, the two-file storage split, and how the language bindings sit on top of a single core.
• Design Choices — What infrastore optimizes for and why, written for developers of parent packages like IS.jl and infrasys.
• Time-Series Types — The seven types, which one your data wants, and the vocabulary they share: periods, timestamp precision, typed arrays.
• Data Model — Owners, features, identity, association ids, and the associations between catalog entities.
• Time References — How a series' timestamps are spelled, what that does and does not change, and why a named zone is safe.
• Readers — The columnar bulk-read surface: why it exists, what one timeline per reader means, and when to reach for something else.
• Storage Model — Why arrays go to HDF5 and metadata goes to SQLite, and how the two stay consistent.
• Content Addressing — How arrays are hashed, deduplicated, and verified.
• Language Bindings — How the Python, Julia, and gRPC interfaces wrap the Rust core.