01Repository index
A semantic index of the repository — files and symbols embedded so the right code can be retrieved for a task, instead of pasting whole directories in and hoping the model reads the relevant part.
AI that understands your codebase.
Most tools read files into a prompt and hope for the best. Sigilix grounds its models in a model of your repository — so a review reasons about your real code, not a plausible guess.
Codebase context is the difference between an answer about code in general and an answer about your code: what exists, how it connects, and what a change touches. This page explains what that means and how Sigilix builds it.
Definition
What is codebase context for AI?
Codebase context is the structured knowledge of a repository an AI system uses to ground its work: which files and symbols exist, how they reference one another, what a change affects, and what kind of project it is. Without it, a model reasons about whatever text happened to land in its prompt — which is code in general, not your code.
Sigilix builds that knowledge into a model of the repository and retrieves the slice that applies to each task. A review of a diff arrives with the changed symbols, their callers and callees, the blast radius, and the repository's role already in view. That is what lets a finding anchor to exact lines and carry evidence instead of a hunch.
It is also the half of the platform that answers what the code is. The other half — the memory index — answers what your team has decided about it. Codebase context plus organization memory is what makes Sigilix org-aware rather than a general assistant pointed at your repo.
The grounding
How Sigilix understands your codebase.
Four kinds of structure, built from the repository, retrieved scoped to each task — so the model starts from your code.
02Symbol & call graph
Definitions, references, and who-calls-what across the repo. A change to a function is read with its callers and callees in view, not as an isolated diff.
03Blast radius
The transitive reach of a change: which modules, tests, and boundaries a diff can affect. Findings are judged against what the change actually touches.
04Repository role
Frameworks, entry points, manifests, test surfaces, and conventions — the shape of the project — so the model knows whether it is reading a worker, a migration, or a UI component.
These are not four features bolted together; they are one grounding layer every surface reads. The same repository model that lets a PR review trace a broken invariant across files lets the CLI answer a question about the code with the right neighbors in view, and lets triage judge a bug against what the change actually touches.
The argument
Grounded vs. pasted into a prompt.
Reading files into a window is not the same as understanding the repository they came from.
| Dimension | Files in a prompt | Grounded in the codebase |
|---|---|---|
| How code enters context | Files are pasted into the prompt, or a retrieval step guesses which snippets are relevant, per request. | Code is retrieved from a model of the repository — semantic index plus symbol graph — scoped to what the task touches. |
| Cross-file reasoning | Limited to whatever files happen to be in the window; callers and callees outside it are invisible. | A change is read with its callers, callees, and blast radius, so cross-file effects are in view. |
| Repository shape | Inferred from the snippets present; the model may not know an entry point from a test helper. | Known: frameworks, entry points, manifests, and test surfaces are classified before the model reads a line. |
| Evidence | Answers cite whatever text was in the prompt. | Findings anchor to exact lines and can be checked against the graph — the basis for evidence receipts in review. |
| Cost as the repo grows | Rises: a bigger repo means more to paste or retrieve per request. | Scoped: the index returns the slice that applies, so context stays proportional to the task, not the archive. |
FAQ
Common questions.
What does it mean for an AI to understand your codebase?
It means the model reasons about your actual repository — its structure, its symbols, and how a change ripples through it — rather than about whatever text was pasted into a prompt. In Sigilix, a task is grounded in a model of the repo: a semantic index for retrieval, a symbol and call graph for cross-file reasoning, and blast-radius analysis for what a change affects. The result is answers about your code, not code in general.
What is codebase context for AI?
Codebase context is the structured knowledge of a repository an AI system uses to ground its work: which files and symbols exist, how they reference each other, what a change touches, and what kind of project it is. Sigilix builds this into a repository index, a symbol and call graph, and role classification, then retrieves the slice relevant to each task — so the model starts from your code instead of a blank guess.
How does Sigilix understand your codebase?
Sigilix indexes the repository into a semantic model — embeddings over files and symbols — and builds a symbol and call graph of definitions, references, and call edges. For any change, it computes blast radius (the transitive set of modules and tests affected) and classifies the repository's role and frameworks. A review or a CLI task then retrieves exactly the context that applies, so reasoning is anchored to real code and findings can carry line-level evidence.
Is Sigilix a codebase intelligence platform?
Yes. Sigilix grounds every surface — code review, issue triage, the CLI, the Slack assistant, and chat — in the same model of your codebase, and pairs it with an organization and developer memory index. Codebase context answers what the code is; memory answers what your team has decided about it. Together they are what make the platform org-aware rather than a generic assistant pointed at your repo.
How is codebase context different from a bigger context window?
A context window is capacity to paste code in; codebase context is a persistent model of the repository the system retrieves from. A bigger window still requires assembling the right code every time and grows more expensive as the repo grows. Grounding scopes context to what a task touches and keeps it proportional to the change, not the archive. The two are complementary — see the memory page for how this pairs with a persistent memory index.
Give the model your codebase, not a copy of some files from it.