@silentsvn - thank you for reading carefully enough to ask this. You're correct that the core scoring is tag‑based and deterministic, which is lexical, not "semantic" in the modern embedding sense. The terminology is worth unpacking.
We call it "semantic" in the broader sense of meaning‑bearing structure—the graph encodes relationships between concepts, and retrieval walks those relationships. But you're correct that at query time, it's matching on tags, not vector similarity.
Why not embeddings?
We made a deliberate trade‑off: determinism and explainability over fuzziness. With vector search, you get a black‑box similarity score and no way to debug why something was retrieved. With tag‑based traversal, you can trace the exact path: "This result matched because it shares tags X, Y, Z and is within 2 hops of your query." That matters for agentic workflows where auditability is critical.
Tag extraction is where we do the work to bridge the lexical gap. The atomization pipeline uses:
- Wink NLP for entity recognition and part‑of‑speech filtering (so "authentication" and "JWT" both get tagged with relevant concepts if they appear in context).
- Co‑occurrence windows to infer relationships (e.g., if "JWT" and "authentication" repeatedly appear near each other, they get linked in the graph).
- Synonym expansion (via Standard 111) so queries for "authentication" can surface nodes tagged with "JWT" if the system has learned that relationship from your corpus.
It's not magic - if you never mention "JWT" in the same context as "authentication," the graph won't connect them. But that's a feature, not a bug: the system reflects your actual usage, not a statistical average of the internet.
The trade‑off is real: you give up the fuzzy "close enough" retrieval of vectors in exchange for perfect traceability and no embedding drift. For many use cases (project memory, execution traces, personal knowledge bases), that's the right call.
I'd love to hear more about what you're building in this space. Always good to find others thinking about these trade‑offs.
I built Anchor because I kept hitting the same wall: local LLMs are great, but every conversation is a fresh start. Vector search is the default hammer, but for structured memory—project decisions, entity relationships, temporal facts—it's often the wrong tool.
Search Moby Dick or Frankenstein and see the tag-based receipts that show why each result matched.
How it works
Anchor uses graph traversal (the STAR algorithm) instead of embeddings. Concepts become nodes, relationships become edges. The database stores only pointers (file paths + byte offsets); content stays on disk, so the index is small and rebuildable. PGlite (PostgreSQL in WASM) lets it run anywhere Node.js does – including a Pixel 7 in Termux, with <1GB RAM.
Performance
- <200ms p95 search on a 28M-token corpus
- <1GB RAM – runs on a $200 mini PC, a Raspberry Pi, or a phone
- Pure JS/TS, compiled to WASM, no cloud dependencies
What’s new in v4.6
- distill: lossless compression of your corpus into a single deduplicated YAML file. I tested it on 8 months of my own chat logs: 2336 → 1268 unique lines, 1.84:1 compression, 5 minutes on a Pixel 7.
- MCP server (v4.7.0) – exposes search and distillation to any MCP client (Claude Code, Cursor, Qwen tools)
- Adaptive concurrency – automatic switching between sequential (mobile) and parallel (desktop) processing
The recursion
I used Anchor to build itself. Every bug fix and design decision is in the graph – that's how I kept the complexity manageable.
Where it fits
If you're building local agents, personal knowledge bases, or mobile assistants and want memory that's inspectable, deterministic, and lightweight – this is for you.
We built Anchor Engine because LLMs have no persistent memory. Every conversation is a fresh start—yesterday's discussion, last week's project notes, even context from another tab—all gone. Context windows help, but they're ephemeral and expensive.
The STAR algorithm (Semantic Traversal And Retrieval) takes a different approach. Instead of embedding everything into vector space, STAR uses deterministic graph traversal. But before traversal comes atomization—our lightweight process for extracting just enough conceptual structure from text to build a traversable semantic graph.
Atomization, not exhaustive extraction.
Projects like Kanon 2 are doing incredible work extracting every entity, citation, and clause from documents with remarkable precision. That's valuable for document intelligence. Anchor Engine takes a different path: we extract only the core concepts and relationships needed to support semantic memory. The result is a graph that's just rich enough for an LLM to retrieve relevant context, but lightweight enough to run offline in <3GB RAM—even on a Raspberry Pi or in a browser via WASM.
Why graph traversal instead of vector search?
Embeddings drift over time and across models
Similarity scores are opaque and nondeterministic
Vector search often requires GPUs or cloud APIs
You can't inspect why something was retrieved
STAR gives you deterministic, inspectable results. Same graph, same query, same output—every time. And because the graph is built through atomization, it stays small and portable.
Key technical details:
Runs entirely offline in <3GB RAM. No API calls, no GPUs.
Compiled to WASM – embed it anywhere, including browsers.
Recursive architecture – we used Anchor Engine to help write its own code. The dogfooding is real.
AGPL-3.0 – open source, always.
What it's not: It's not a replacement for LLMs or vector databases. It's a memory layer—a deterministic, inspectable substrate that gives LLMs persistent context without cloud dependencies. And it's not a competitor to deep extraction models like Kanon 2; they could even complement each other (Kanon 2 builds the graph, Anchor Engine traverses it for memory).
We're especially interested in feedback from people who've built RAG systems, experimented with symbolic memory, or worked on graph-based AI. If you've ever wanted to give an LLM long-term memory that fits on a Raspberry Pi, this might be interesting to you.
We built Anchor Engine because LLMs have no persistent memory. Every conversation is a fresh start—yesterday's discussion, last week's project notes, even context from another tab—all gone. Context windows help, but they're ephemeral and expensive.
The STAR algorithm (Semantic Traversal And Retrieval) takes a different approach. Instead of embedding everything into vector space, STAR uses deterministic graph traversal. But before traversal comes atomization—our lightweight process for extracting just enough conceptual structure from text to build a traversable semantic graph.
Atomization, not exhaustive extraction.
Projects like Kanon 2 are doing incredible work extracting every entity, citation, and clause from documents with remarkable precision. That's valuable for document intelligence. Anchor Engine takes a different path: we extract only the core concepts and relationships needed to support semantic memory. The result is a graph that's just rich enough for an LLM to retrieve relevant context, but lightweight enough to run offline in <3GB RAM—even on a Raspberry Pi or in a browser via WASM.
Why graph traversal instead of vector search?
Embeddings drift over time and across models
Similarity scores are opaque and nondeterministic
Vector search often requires GPUs or cloud APIs
You can't inspect why something was retrieved
STAR gives you deterministic, inspectable results. Same graph, same query, same output—every time. And because the graph is built through atomization, it stays small and portable.
Key technical details:
Runs entirely offline in <3GB RAM. No API calls, no GPUs.
Compiled to WASM – embed it anywhere, including browsers.
Recursive architecture – we used Anchor Engine to help write its own code. The dogfooding is real.
AGPL-3.0 – open source, always.
What it's not: It's not a replacement for LLMs or vector databases. It's a memory layer—a deterministic, inspectable substrate that gives LLMs persistent context without cloud dependencies. And it's not a competitor to deep extraction models like Kanon 2; they could even complement each other (Kanon 2 builds the graph, Anchor Engine traverses it for memory).
We're especially interested in feedback from people who've built RAG systems, experimented with symbolic memory, or worked on graph-based AI. If you've ever wanted to give an LLM long-term memory that fits on a Raspberry Pi, this might be interesting to you.
We call it "semantic" in the broader sense of meaning‑bearing structure—the graph encodes relationships between concepts, and retrieval walks those relationships. But you're correct that at query time, it's matching on tags, not vector similarity.
Why not embeddings? We made a deliberate trade‑off: determinism and explainability over fuzziness. With vector search, you get a black‑box similarity score and no way to debug why something was retrieved. With tag‑based traversal, you can trace the exact path: "This result matched because it shares tags X, Y, Z and is within 2 hops of your query." That matters for agentic workflows where auditability is critical.
Tag extraction is where we do the work to bridge the lexical gap. The atomization pipeline uses: - Wink NLP for entity recognition and part‑of‑speech filtering (so "authentication" and "JWT" both get tagged with relevant concepts if they appear in context). - Co‑occurrence windows to infer relationships (e.g., if "JWT" and "authentication" repeatedly appear near each other, they get linked in the graph). - Synonym expansion (via Standard 111) so queries for "authentication" can surface nodes tagged with "JWT" if the system has learned that relationship from your corpus.
It's not magic - if you never mention "JWT" in the same context as "authentication," the graph won't connect them. But that's a feature, not a bug: the system reflects your actual usage, not a statistical average of the internet.
The trade‑off is real: you give up the fuzzy "close enough" retrieval of vectors in exchange for perfect traceability and no embedding drift. For many use cases (project memory, execution traces, personal knowledge bases), that's the right call.
I'd love to hear more about what you're building in this space. Always good to find others thinking about these trade‑offs.