The scoring breakdown — textual against semantic against functional — is the part that makes the bias claim checkable rather than a slogan: you can see when a hit is winning on comments and discount it yourself. Updates are agent-driven by design rather than filesystem-watched, which is what lets the whole thing run in a container: after your assistant changes a file, it calls the update tool, and the index stays honest.
A code retrieval server implementing the SACL framework, aimed at one specific failure: search systems over-weight docstrings, comments and variable names, so nicely-commented code outranks the function that actually does the job. It detects that textual bias, augments the code's semantic representation, and reranks on functional relevance — then returns results with their related components from a knowledge graph.
- `query_code` runs bias-aware search with a scoring breakdown across textual, semantic and functional signals, plus a ranking explanation
- `query_code_with_context` adds relationship context — related components, dependency chains and a relationship graph
- `analyze_repository` performs the initial full scan, with an `incremental` option for later passes
- `get_relationships` maps a file's imports, exports, calls, extends, implements, uses and depends_on links to a depth you choose
- `get_file_context` returns the surrounding context for one file
- `update_file` and `update_files` re-analyse after changes, one file or a batch
- `get_bias_analysis` reports where textual bias was detected, and `get_system_stats` reports the state of the index
Node.js 18+, a Neo4j instance for the knowledge graph, and an OpenAI API key — `OPENAI_API_KEY` is required, with `NEO4J_URI`, `NEO4J_USER` and `NEO4J_PASSWORD` alongside it. `npm install` locally, or bring the whole stack up with the supplied `docker-compose`. Embeddings are billed against your OpenAI key, and repository analysis embeds the codebase, so the first full scan is where the cost lands.
