From 6d05f510d8fe85b2668f14321df18919995f2cad Mon Sep 17 00:00:00 2001
From: Denis Drobyshev <drobishev.denis@icloud.com>
Date: Thu, 27 Aug 2026 13:32:15 +0300
Subject: [PATCH] Describe the retrieval that runs, not the one that is
 designed

The stack card explained a design decision for a component that is not wired.
psycopg and the pgvector Python package are declared in praxis's api extra and
imported nowhere in its source tree; src/praxis/index/ is a lone schema.sql;
and docker-compose starts a db service the app does not depend on and never
connects to.

What actually serves 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.

The card now says that, and names the Postgres path as designed rather than
present. This was my error: I inferred the architecture from the compose file
and the extras instead of reading the retrieval path, which is the mistake rule
three exists to prevent.

Context and the options for closing the gap: DrobyshevDev/praxis#26.
---
 index.html    | 9 +++++----
 ru/index.html | 9 +++++----
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/index.html b/index.html
index d340f4f..6f25032 100644
--- a/index.html
+++ b/index.html
@@ -330,11 +330,12 @@ <h2>What these are built on, and why</h2>
         </article>
 
         <article class="card">
-          <div class="card-top"><h3>FastAPI · Postgres · pgvector</h3><span class="tag">praxis</span></div>
+          <div class="card-top"><h3>FastAPI · NumPy</h3><span class="tag">praxis</span></div>
           <p>
-            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.
           </p>
         </article>
 
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 @@ <h2>На чём это построено и почему</h2>
         </article>
 
         <article class="card">
-          <div class="card-top"><h3>FastAPI · Postgres · pgvector</h3><span class="tag">praxis</span></div>
+          <div class="card-top"><h3>FastAPI · NumPy</h3><span class="tag">praxis</span></div>
           <p>
-            Одно API-ядро обслуживает всех клиентов. pgvector держит плотный индекс в той же базе,
-            что и корпус: нет второй системы, которую надо синхронизировать, и отдельной истории с
-            бэкапами для той части, что делает ответы.
+            Одно API-ядро обслуживает всех клиентов. Плотный поиск — умножение матрицы на вектор
+            по векторам в памяти с кэшем на диск, плюс запасной путь на чистой стандартной
+            библиотеке, чтобы офлайн-образ и CI работали вообще без NumPy. Индекс на Postgres с
+            pgvector спроектирован, но не подключён: схема в репозитории есть, ретривера нет.
           </p>
         </article>