Replication
Separate durable vector transport from local HNSW population.
Records and index are different layers
Basis has no network client or listener. Its vector strand stores add/remove records; a separately configured transport may move those records between peers. Receiving them does not populate HNSW. Basis::new starts with an empty graph, and the SDK does not automatically replay the vector log.
WeaveNode::start_auto_replication announces strands held in the node's ordinary Strand store. It does not provide a complete Basis replication-and-rebuild workflow. Calling it after open_basis is not proof that another peer has the vectors or can query them.
Application integration requirements
- Identify and authorize the actual vector record stream.
- Configure transport, writer-key verification and storage for that stream.
- Build a local query index from a validated source corpus through an explicit application workflow.
- Check recovered identifiers, vector dimensions and query results before serving requests.
The private rebuild helper is not a public restore endpoint, and present-id removal can deadlock. See Snapshot and Recovery.
HNSW construction is randomized. Even when two indexes contain the same vectors, no bitwise-identical graph, query order or fixed recall bound is established by this documentation. Measure recall and rerank candidates if the application needs deterministic ordering.
A multi-writer materialized vector view is an application design to implement and test; it is not a built-in Nexus-to-Basis adapter demonstrated here. For a working in-process example, use the numeric-vector tutorial.
