elips/docs
Chapter XI · internals

Architecture — the whole stack

Lesson 21← back to roadmap

Every ELIPS feature lives on exactly one of five layers. Knowing which one is the difference between a one-line patch and a refactor.

surfacesPython · modernClient · CollectionPython · coreopen · VaultC++23 SDKelips::openelips CLIops & replDatabaselifecycle · config · WAL · collection registryCollectionrecords · planner · index · metadataquery pathsearch / scan / hybridtext pathadd_documentpersistenceWAL · segmentslockingflock RO / RW← composition root
SDKs → Database → Collection → planner + ports (index/metadata/text/GPU) → storage (WAL + segments).

From docs/architecture/system-overview.md: each layer talks down to the next via abstract ports. Nothing in the planner depends on a concrete index. Nothing in the index depends on a concrete storage layout.

Indexbuild · upsert · search · removeIndexHNSWM · ef_construction · ef_searchIndexFlatbrute force · deterministicGPU familybf_knn · ivf · pq · sqlog-ish recall@k100% recall, O(N) per querybatched, async, GpuBackend-boundone contract — the planner doesn't care which
Ports & adapters: the planner sees Index, MetadataIndex, TextEmbedderPort, GpuBackend — not concrete classes.
Edit on GitHub →