AI agents can find relevant passages. But as documents arrive and change, rankings, neighbors, and top results can change too. Without source and revision history, it is hard to see what evidence informed an answer - or how that evidence changed.
Immutlex gives AI your organization’s knowledge as a connective memory layer.
The viewer lets people read, write, inspect, and explore that memory. Agents and applications work with the same evolving knowledge through MCP, CLI, and the Python SDK.
For example:
Question: Who owns this migration now, and which services and projects does it touch?
Immutlex: Finds current records, follows their connections, and returns source-linked evidence with revision history.
From company history to working context
Company knowledge is never a static moment in time. Plans change, people move between teams, projects pick up old systems, and decisions get superseded. AI memory needs to retain those episodes and still build working context for what matters now.
Freeze the semantic layer and it stops reflecting the business. Let the corpus grow without revision and relationship management, and old or conflicting records can keep competing with current knowledge. Immutlex preserves source revisions and connections, then derives current lexical, semantic, and graph views from that record.
Company memory is a workload, not a shopping list of database features: multimodal records change over time; authored links must stay distinct from retrieval signals; indexes must follow source revisions; and writes must be recoverable. Immutlex is built around that lifecycle. One Rust engine owns ingestion, revision identity, WAL tracking, BM25 and HNSW indexing, and graph products. The object store retains the source material; search and graph structures are engine-maintained views derived from it. Their shared data model and lifecycle are what make Immutlex an engine, rather than a collection of stores that application code has to reconcile.
An LLM can answer confidently from missing or stale context. It can also generate a plausible relationship without making that relationship a recorded fact. Source revisions and typed edges give people and agents a basis to inspect and update memory as the organization changes.
Search the current corpus; keep the source trail
Immutlex preserves source material and immutable document revisions in the configured object store. Ingest stages are recorded in a write-ahead log so interrupted work can be inspected and replayed from its source.
Search indexes and retrieval relationships are derived from that record:
| Index | What it finds |
|---|---|
| BM25 | Exact terms and shared vocabulary |
| HNSW | Semantically related passages, including ones that use different words |
| Reciprocal Rank Fusion | A combined ranking from lexical and semantic results |
Add or revise documents and the same query may return different top results. Immutlex ties retrieved evidence to its source document and revision while the indexes answer against the current corpus. People and agents can inspect and explore the same memory independently, asynchronously, or together.
Connect records with typed edges
| Edge | What it represents | Why it helps |
|---|---|---|
| Explicit | Authored wiki links and relationships stored with document revisions | Preserves chosen connections and supports graph operations and analytics |
| Lexical | Neighbors found through BM25 co-retrieval | Connects records that share important terms |
| Semantic | Neighbors found through HNSW | Connects related material that uses different words |
| Implicit | Neighbors found by both lexical and semantic retrieval | Surfaces agreement between the two search signals |
Authored edges remain part of the document history. Retrieval edges are derived from the current corpus and can change as it grows. When a suggested connection should become part of the record, a person or agent can promote it to an authored link in a new revision.
Account for work at write time
Ingesting knowledge takes compute and time. Immutlex parses and chunks new or changed material, runs local embedding models, and applies OCR where needed. That inference uses local resources and adds ingest latency. The work scales with the content being processed.
Some systems run an LLM to extract facts and relationships on every write. Each call adds inference cost and time before that write is ready. Immutlex bundles its embedding and OCR models and runs them locally; answer generation happens separately through the model your team chooses.
A full derived-neighbor build makes one pass over chunks, then considers a bounded candidate set per document. Its work is roughly O(C + D × K): C chunks, D documents, and K the configured candidate limit. With K fixed, doubling the corpus roughly doubles that build work; it does not require comparing every document pair.
Use the same memory in agents, workflows, and apps
Immutlex exposes search, document, and graph operations through MCP over stdio and HTTP/SSE. People can edit documents in the viewer; saves create new revisions. Agents can retrieve source-backed context and follow connections.
Engineers and DevOps teams can use the CLI and Python SDK in GitHub Actions, Azure DevOps, and their own applications. Those integrations can read, write, and act on organizational memory - not only return semantically similar passages.
Run it inside your boundary
The native Rust binary bundles MiniLM-L6-v2 for text embeddings, Jina code embeddings, SigLIP image embeddings, and local OCR. Embedding and OCR do not require a hosted model API; generation uses the model your team approves.
Run Immutlex on one host with RustFS alongside it, against S3-compatible object storage or Azure Data Lake Storage Gen2, in Kubernetes, or inside an air-gapped network. Object storage is part of the architecture and belongs in the deployment plan.