Describe the retrieval that runs, not the one that is designed

[DenisDrobyshev]

The Stack card explained a design decision for a component that is not wired.

grep -rn "psycopg" --include=*.py .          -> no matches
grep -rln "postgres|POSTGRES|DSN|dbname" src -> no matches
find src/praxis/index -type f                -> schema.sql only

psycopg and the Python pgvector package are declared in praxis's api extra and imported nowhere. docker-compose.yml starts a db service the app service does not depends_on and never connects to.

What actually serves dense retrieval, per its own docstring in retrieve/dense.py, 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.

What the card says now

FastAPI · NumPy, describing that path, and naming the Postgres index as designed and not yet wired — the schema is in the repository, the retriever is not.

Why this matters more than a wording fix

The eval figures this site prints — recall@5 0.92, MRR 0.94 — come from the NumPy path. A reader who sees "Postgres · pgvector" reasonably assumes they were measured on an HNSW index with vector_cosine_ops. The numbers are honest about what they measured; the stack line was not honest about what produced them.

This was my error rather than an inherited one: I inferred the architecture from the compose file and the extras instead of reading the retrieval path. That is precisely the mistake rule three exists to prevent, on the page that prints rule three.

Context and the three options for closing the gap: DrobyshevDev/praxis#26.

Verified

check_site.py passes on all four pages. "Postgres" now appears once per language page, in the sentence that says it is not connected.