Terraphim -- Privacy-First AI Search

Capabilities

Search engine

Five algorithms compete on every query

TitleScorer, BM25, BM25F, BM25Plus, and TerraphimGraph run concurrently across your haystacks. Results are ranked and merged in under 200ms. The best answer surfaces regardless of which algorithm found it.

Privacy

Local-first architecture

Every index, graph, and query stays on your machine. No telemetry, no cloud dependency. You choose whether to connect external services.

Knowledge graphs

Aho-Corasick automata

Build thesauri from documents. The automata engine extracts concepts using LeftmostLongest matching, constructing rolegraphs that adapt to each user profile and domain vocabulary.

Isolation

Firecracker microVMs

Run untrusted code in fully sandboxed VMs with sub-2-second boot. The pooling system pre-warms instances for under 500ms allocation.

Modularity

29 specialised crates

Search, persistence, agent orchestration, knowledge graphs, and haystack integrations -- each crate does one thing well. Rust edition 2024 with resolver version 2 for optimal dependency resolution.

In action

terraphim-agent

$ terraphim-agent Terraphim Agent v0.9.0 Role: Terraphim Engineer Relevance: TerraphimGraph Haystacks: ripgrep, confluence, discourse, quickwit ------------------------------------------------------ terraphim> /search "persistence layer cache warm-up" Searching 4 haystacks... Results (TerraphimGraph ranked): 1. Cache Write-back with Fire-and-Forget 0.96 2. Multi-Backend Storage Abstraction 0.89 3. OpenDAL Operator Ordering by Speed 0.84 4. Zstd Compression for Large Objects 0.78 5. Schema Evolution and Cache Invalidation 0.72 Completed in 167ms across 1,463 documents terraphim> /vm list VM Pool: 3 warm, 0 cold Avg boot: 1.4s | Avg alloc: 380ms Execution mode: hybrid (local + firecracker) terraphim> /chat "explain the cache write-back pattern" When data loads from a slower fallback operator (SQLite, S3), the persistence layer automatically caches it to the fastest operator (memory, dashmap) using a fire-and-forget tokio::spawn pattern. Objects over 1MB are compressed with zstd. If cached data fails to deserialise, the entry is deleted and refetched from persistent storage transparently.

Design principles

Your data stays yours

No telemetry. No cloud calls unless explicitly configured. Every search runs on your hardware, with your indices, on your terms. Optional LLM providers connect only when you choose.

Compete, then merge

Five relevance algorithms run concurrently on every query. Results are ranked independently, then merged. The best answer wins regardless of which algorithm found it.

One crate, one job

29 crates, each with a single responsibility. Search, persistence, automata, configuration, agents, haystacks -- clean boundaries, minimal coupling, maximum composability.