Inside Cora Code: How Semantic Analysis Actually Works

Most code review tools compare diffs syntactically — line additions, deletions, and context windows. Cora Code takes a different approach. It builds a semantic model of your entire codebase and uses that model to understand what your changes mean, not just what they look like.

The Three-Layer Architecture

Layer 1: Structural Understanding via Tree-sitter

Cora Code uses tree-sitter for AST extraction across 13 languages: Rust, Go, Python, TypeScript, JavaScript, Svelte, Dart, Java, C, C++, C#, Ruby, PHP, and Scala. Tree-sitter gives us the actual syntax tree — not regex matches, not line-by-line heuristics. We extract functions, structs, traits, enums, interfaces, classes, and their relationships.

For languages where tree-sitter grammars are incompatible (like Svelte), we use a Strip and Delegate pattern: extract the inner language content (TypeScript from script tags), then parse it with a compatible grammar. Zero new dependencies.

Layer 2: Knowledge Graph with Typed Edges

Extracted symbols go into a SQLite database (cora.db) with a projects table for multi-repo support. Symbols are connected by typed edges: CALLS, IMPORTS, IMPLEMENTS, INHERITS, and CHILD_OF. This is not just a call graph — it is a full knowledge graph that supports traversal in any direction.

This is what powers cora callers, cora impact, and cora trace. When you ask who calls a function, you get a precise answer based on AST-derived edges, not text search.

Layer 3: Brain Mode — Hybrid Semantic Search

Brain Mode combines three signals using Reciprocal Rank Fusion (RRF) with k=60: FTS5 keyword search for exact matches, usearch HNSW vector search for semantic similarity, and graph BFS for structural proximity. The three signals are fused into a single ranked result set.

Embeddings are generated at index time using a static token approach — a hashing trick that produces 256-dimensional vectors with zero runtime dependencies. No ONNX, no model downloads, no GPU. Each vector takes 0.7 microseconds to compute. The full 1,700-symbol index embeds in under a second.

Performance Numbers

• Brain search (warm): 37ms
• Brain search (cold): 52ms
• Hash embed per vector: 0.7 microseconds
• Full index rebuild (1,700 symbols): 5.3 seconds
• usearch KNN query: ~25ms (68% of search time)

Fifty queries per session adds roughly 1.8 seconds of total search overhead. This is fast enough to use interactively during development.

Why This Matters for Code Review

When cora review analyzes a diff, it has access to the full codebase context. If you add a new function, it can check whether similar logic already exists. If you modify an interface, it can trace every implementation. If you remove a function, it can identify every caller that will break.

This is fundamentally different from diff-only review tools that see your changes in isolation. The knowledge graph turns code review from pattern matching on text into reasoning about structure.

The Embedding Roadmap

The current static token embeddings cover roughly 80% of retrieval quality. The planned upgrade to Voyage-4-Nano ONNX (Matryoshka 256d) would use the same 256 dimensions, meaning the entire usearch index infrastructure stays the same. Swap the embedding function, re-index, and you get contextual embeddings with zero schema changes. This is the Matryoshka advantage — same index, better vectors.