Why one server
Knowledge only counts when someone owns it, has approved it, may see it and knows how fresh it is. One place applies those rules to every reader, so no client can skip them.
Architecture
How Lore fits together.
One server holds the rules: who owns an entry, who may read it, how fresh it is. Everything else, the app people use, the assistants and the tools around them, reaches knowledge only through it.
The pieces
One server in the middle, every reader through it.
People use the app; assistants speak MCP. Both meet the same server, which applies the same access to every read, keeps everything in one database and runs its own small models.
Who reads
PeopleThe app: in a browser, the desktop app or Lore Local
the app · HTTPS
AssistantsClaude Code, Codex, Cursor, Windsurf, GitHub Copilot, any that speaks MCP
MCP · the brief
loreConnects each assistant; runs Claude Code's hook and status line
the hook
The Lore serverOne Java process. The same jar runs for one person or as replicas on Kubernetes.
Searchkeywords, identifiers, typos and meaning, then a reranker
Askanswers from approved entries, each cited
Review and freshnessnothing published unseen; every entry verified or due a re-check
Gaps and jobswhat nobody could answer; indexing, sources, digests
Access per area, applied inside every read: the app's, Ask's and every assistant's
Postgres with pgvectorEntries, passages, their vectors, links, logs, settings: one transaction per change
Three local modelsEmbedding, search and reranker, run inside the server; no text leaves it for them
Around it, when you add them
mirrored, read-only
ConnectorsSlack, Jira, Confluence, Google Drive, Notion, Linear, under each source's access
Ask's writer, your choice
Answer enginesA model on this computer, Claude or another hosted one; or none, and Ask lists entries
searched as one
Linked LoresOther Lores a person may see; nothing copied
events out
Your other toolsWebhooks, or Kafka and RabbitMQ with a plugin
Why one database
An entry, its passages, their vectors and its review change together or not at all. With the vectors beside the text there is no second store to keep in step, and backups are one dump.
Why local models
Search by meaning, across languages, and a reranker that judges whether a passage answers the question: the reason the hook can stay quiet when nothing does.
A search
One pipeline answers everyone.
The app's search, an assistant's search and brief, the hook, Ask's sources and a linked Lore's search all run the same steps.
- 1The questionAs the reader asks it, with their access
- 2UnderstoodThe team's glossary and spelling
- 3Four retrievers at onceKeywordsIdentifiersTypos in titlesMeaningEach only over what the reader may read
- 4One scoreTheir signals fused and calibrated
- 5The rerankerReads the best candidates within 150 ms
- 6The floorWeak results never reach an assistant
An assistant's turn
Quiet unless it has something.
In Claude Code, the lore command's hook sees each prompt. Any assistant can ask for a brief of its task over MCP. Both answer only when an entry clears the floor on its own.
You type a promptin Claude Code
The hooksends it to Lore, waiting two seconds at most
A judged searchthe reranker always reads the best six
an entry clears the floor
One lead, citedadded to the prompt's context
nothing does: the common case
Nothing98% of unrelated prompts get no words at all
Where it runs
The same server, in two shapes.
What changes is who starts it and where its database comes from.
Lore Local, for one person
One app
The app's windowand a supervisor that starts and stops the rest
The serverwith its own Java runtime, on this computer only
Postgresits own port
The modelsthree, inside
lorethe command, bundled
MCP · the hook, no token
Assistants on this computer
A team server
Each person's computerthe desktop app or a browser; assistants and
loreHTTPS, a token on every request
Your servers: compose on one machine, or Kubernetes
Serverreplica
Serverreplica
One Postgresbundled or managed; migrations before each upgrade
Where data lives
Everything in one database, nothing kept beside it.
The server keeps no state of its own that a second replica would miss. An entry is split into passages at its headings, each passage gets its vectors, and an event out is written in the same transaction as the change it reports, so none is lost or invented.
On Lore Local
The app's own folder, private to you: the database, its backups (three kept) and the model cache. The database password is in the system's keychain.
On a team server
The database you give it. The image writes only its checkouts, its backups and temporary files; logs go to standard output.
On each computer
The lore command and a backup of every file it changed. Its token is in the system's keychain, never in a file.