Indexion: The Codebase Map That Refuses to Drift
How a MoonBit tool uses KGF, semantic grep, and an embedded wiki to turn source code into a living system of search, documentation, and repair.
- Indexion is built to make a repository answer for itself, not just help you look around inside it.
- Its KGF layer turns many languages into one structural vocabulary, which makes cross-language search and similarity practical.
- The embedded wiki is part of the indexed system, so documentation is checked against code instead of living beside it.
- Plan reconcile matters because it converts drift from a quiet failure into an explicit maintenance task.
Indexion looks like a search tool until you notice what it is really optimizing for. It wants the repository to stay legible as it changes, which means code, docs, and AI context all need to be compared against the same internal map. That makes it less of a finder and more of a truth-maintenance layer for a fast-moving codebase.
The Repo as a Living Map
The simplest way to understand indexion is to stop thinking about search as an end in itself. Here, code files, wiki pages, semantic matches, and reconcile plans all live inside one shared model of the repo. The point is not to answer, “Where is this symbol?” The point is to answer, “What does the repository believe about itself, and is that belief still true?”
That is why the project feels unusually opinionated. It assumes a repository is not just a pile of files. It is a system with claims, and those claims can drift.
Why KGF Matters
KGF is the abstraction that makes the whole thing work across languages. Instead of building a bespoke parser strategy for every syntax, indexion normalizes source into shared structural features. The result is a common vocabulary for functions, declarations, comments, wrappers, and other code shapes that matter to search and documentation checks.
indexion grep "pub fn *"
indexion semantic undocumented
indexion semantic proxy| Dimension | Traditional grep | Indexion with KGF |
|---|---|---|
| What it matches | Strings and regex patterns | Structural tokens and code features |
| Cross-language use | Weak unless syntax happens to align | Strong because language-specific surface forms normalize into shared kinds |
| Useful for docs | Not really | Yes, because code shape and comment coverage can be queried together |
| Main failure mode | Too literal | Depends on the quality of the KGF mapping, not just the query |
That last row matters. Indexion is not magic. It trades the old problem of brittle text matching for a new problem: maintaining a good structural model. But once that model exists, the search surface gets much sharper.
Searching for Structure, Not Strings
The project’s grep and semantic layers are the practical payoff of KGF. Standard grep asks whether a pattern appears in text. Indexion asks whether a pattern appears in the shape of the code. That distinction is what lets it detect public declarations without comments, wrapper functions that merely delegate, and other repo smells that a text search would miss or bury in noise.
# Conceptually:
TokenMatcher::Kind("pub")
TokenMatcher::Text("fn")
TokenMatcher::Ellipsis
SemanticQuery::Undocumented
SemanticQuery::ProxyThis is also where the tool starts to feel useful to an AI assistant, not just a human. A language model can hallucinate structure if it only sees raw text. A structural index gives it a better frame of reference: symbols, relationships, and the difference between a definition and a dead wrapper.
The Embedded Wiki Is the Other Half of the System
The embedded wiki is not an appendix. It is part of the corpus. By keeping documentation inside .indexion/wiki and indexing it alongside source code, the project puts prose and implementation under the same roof. That is the trick that makes drift visible. A README claim can be compared against actual symbols, not just against memory.
This matters because many repos fail in a boring way. The code moves, the docs lag behind, and the mismatch becomes normalized. Indexion is designed to make that mismatch uncomfortable.
Plan Reconcile: The Part That Fights Drift
Plan reconcile is the operational climax. It turns a structural mismatch into an action list. A changed function signature, a stale README reference, or a missing explanation in the wiki becomes a visible discrepancy instead of a quiet source of confusion.
| Stage | What happens | What the user sees |
|---|---|---|
| Code change | A file or symbol shifts | A new version enters the index |
| Map update | KGF and corpus layers rebuild relationships | Search and semantic views refresh |
| Drift check | Docs are compared with source structure | Warnings appear where claims no longer match |
| Reconcile | Suggested repairs are produced | README or wiki updates become explicit work |
The important shift is psychological as much as technical. Indexion does not wait for a human to notice that the docs are stale. It turns staleness into a first-class output.
Why MoonBit Is Not Just a Footnote
MoonBit is easy to treat as a novelty, but here it reads like a strategic choice. A repo exploration engine needs fast parsing, modular code, and a disciplined build story. MoonBit gives the project a language that seems unusually aligned with those needs, which helps explain why the codebase can stay so structured even while it spans search, similarity, wiki indexing, and planning.
That said, the language is a means, not the message. The message is the product shape: a tool that wants to keep meaning attached to source as the repository evolves.
What Indexion Is Really Optimizing For
Indexion is built for large, multilingual repos where human memory is weak and documentation ages fast. It is also built for a world where AI assistants need more than raw text to stay honest. The project’s real ambition is to make the repo itself a reliable interlocutor. Code changes. The map updates. The docs either keep up or get called out.
That is why the name feels right. It is not just indexing. It is trying to keep the index worthy of trust.
