diff --git a/index.html b/index.html
index d340f4f..6f25032 100644
--- a/index.html
+++ b/index.html
@@ -330,11 +330,12 @@
What these are built on, and why
- FastAPI · Postgres · pgvector
praxis
+ FastAPI · NumPy
praxis
- One API core serves every client. pgvector keeps the dense index in the same database
- as the corpus, so there is no second system to keep in sync and no separate backup
- story for the part that makes answers.
+ One API core serves every client. Dense retrieval is a matrix-vector product over
+ vectors held in memory and cached to disk, with a pure standard-library fallback so
+ the offline image and CI run without NumPy at all. A Postgres index with pgvector is
+ designed and not yet wired — the schema is in the repository, the retriever is not.
diff --git a/ru/index.html b/ru/index.html
index 617e2ef..d144b53 100644
--- a/ru/index.html
+++ b/ru/index.html
@@ -328,11 +328,12 @@ На чём это построено и почему
- FastAPI · Postgres · pgvector
praxis
+ FastAPI · NumPy
praxis
- Одно API-ядро обслуживает всех клиентов. pgvector держит плотный индекс в той же базе,
- что и корпус: нет второй системы, которую надо синхронизировать, и отдельной истории с
- бэкапами для той части, что делает ответы.
+ Одно API-ядро обслуживает всех клиентов. Плотный поиск — умножение матрицы на вектор
+ по векторам в памяти с кэшем на диск, плюс запасной путь на чистой стандартной
+ библиотеке, чтобы офлайн-образ и CI работали вообще без NumPy. Индекс на Postgres с
+ pgvector спроектирован, но не подключён: схема в репозитории есть, ретривера нет.