# Knowledge Representation -- Cross-Comparison Review

**Last updated:** 2026-05-10

This directory contains comparisons of @coda/search against systems focused on knowledge representation, compilation, and comprehension. These systems address the question: how should knowledge be structured, accumulated, and maintained for AI consumption?

---

## Compared Systems

| Project                            | Stars          | Type                             | Our Verdict                                  |
| ---------------------------------- | -------------- | -------------------------------- | -------------------------------------------- |
| [Graphify](graphify-comparison.md) | 45,690         | Codebase knowledge graph builder | Different domain; no techniques to adopt     |
| [GitNexus](gitnexus-comparison.md) | 38,634         | Code intelligence + Graph RAG    | Different domain; no techniques to adopt     |
| [LLM Wiki](llm-wiki-comparison.md) | 6,605 (nashsu) | Knowledge compilation pattern    | Adopt the philosophy, not the implementation |
| [RLMs](rlm-comparison.md)          | 4,196          | Recursive inference paradigm     | 1 idea adopted (PR-198), 2 remaining         |

---

## Cross-Cutting Findings

### 1. Knowledge compilation is the key philosophical gap

The LLM Wiki pattern articulates our most significant architectural gap: **knowledge should be compiled once and kept current, not re-derived on every query.** Today, when the agent searches for "royalty payments," it gets raw schema entries and must figure out what each table means every time. Our glossary partially addresses this but is hand-curated and thin.

### 2. Codebase comprehension is a solved problem we don't need

Graphify (45.7K stars) and GitNexus (38.6K stars) are the market leaders for turning code into navigable knowledge graphs. But our corpus is structured schema metadata, not code. AST parsing, LLM extraction, and community detection are all irrelevant to our use case. If we ever need codebase comprehension for the AI agent itself, both offer strong MCP-first integration patterns (GitNexus with 16 MCP tools, Graphify with 7 MCP tools + 18 platform integrations).

### 3. Graph-seeded retrieval adds no value over our existing signals

Both Graphify (BFS/DFS traversal) and RLMs (recursive decomposition) suggest graph-based retrieval patterns. Our `ProximitySignal` already captures graph-local relevance with better anchor selection (vector candidates vs keyword matches). Adding another graph traversal signal would duplicate existing coverage.

### 4. Recursive/iterative search has untapped potential

RLMs' idea of multi-pass retrieval (search -> analyze results -> search again with refined terms) maps to pseudo-relevance feedback. Our `ProximitySignal` does one form of this (expand via graph from vector candidates), but a second keyword pass seeded by first-pass results is unexplored.

---

## What We Adopted

| Pattern                            | Source   | Status                                                             |
| ---------------------------------- | -------- | ------------------------------------------------------------------ |
| REPL-style graph exploration tools | RLMs     | **DONE (PR-198)** -- FindJoinPath, GetNodeNeighbors, GetNodeDetail |
| Glossary linting / health checks   | LLM Wiki | **DONE** -- `lintGlossary()` with 5 check types                    |
| Adamic-Adar neighbor specificity   | LLM Wiki | **DONE (PR-198)** -- `AdamicAdarSignal` as `StaticSignal`          |

---

## What We Should Adopt Next

### From LLM Wiki: Knowledge feedback loops (HIGH priority)

The single largest gap the LLM Wiki pattern exposes. Our `ReportUsage` endpoint is a stub. Wiring it up to persist `(query, selected_ids, timestamp)` tuples would enable:

- Identifying which tables are selected together (implicit relationships)
- Detecting zero-result queries (glossary gaps)
- Measuring per-query interpretation cost

### ~~From nashsu/llm_wiki: Adamic-Adar signal~~ (DONE)

~~Their 4-signal knowledge graph relevance model includes Adamic-Adar (shared-neighbor weighting).~~ Implemented as `AdamicAdarSignal` — a `StaticSignal` that sums `1/log(degree)` across neighbors, ranking nodes with rare neighbors higher than those connected only to hubs.

### From LLM Wiki: Louvain community detection (LOW priority)

Automatic clustering of schema items by link topology could surface domain groupings without manual glossary curation. Worth evaluating when automated glossary generation is on the roadmap.

### From RLMs: Task complexity-aware result depth (LOW priority)

Classify queries by estimated complexity and adjust result shape: O(1) queries get few results with full detail; O(n) queries get many results with summaries. Not started; pursue when retrieval gap analysis reveals specific failures.

---

## Determinism Comparison

| System           | Deterministic? | Notes                                                                 |
| ---------------- | -------------- | --------------------------------------------------------------------- |
| **@coda/search** | Yes            | Same query, same results. Fully deterministic pipeline.               |
| **Graphify**     | No             | Issue #741: ~11K-line diffs on unchanged source. Known quality issue. |
| **LLM Wiki**     | No             | LLM-generated pages vary between runs.                                |
| **RLMs**         | No             | Emergent strategies vary between runs.                                |

Our determinism is a significant enterprise advantage -- auditable, reproducible, testable.

---

## Recommendations

1. **Wire up ReportUsage** for knowledge feedback loops (the key insight from LLM Wiki)
2. **Enrich glossary entries** with `relationships`, `gotchas`, and `related_concepts` fields
3. ~~**Evaluate Adamic-Adar** as a `StaticSignal` for shared-neighbor boosting~~ — DONE (`AdamicAdarSignal`)
4. **Monitor Graphify's cross-language bridge** (#767) for potential cross-datasource join discovery