Context Graph
By the end of this page you will know what the Context Graph gives you, the four things it is made of, and whether your codebase is a fit.
Prerequisites
- A project. Admin or Developer role.
- A repository in GitHub or Azure DevOps, or a zip of one.
What it does
Give it an existing codebase and it returns a map of that codebase plus a search over it that understands meaning. It reads the code; it never runs it.
That is what lets an agent work on an application nobody on your team wrote — fix a bug in it, add a feature to it, or judge whether a proposed change is safe.
Open it from Context Graph in the project sidebar.
Two things, two different questions
Each ingest produces two linked artifacts, because they answer different questions:
| Question | Answered by |
|---|---|
| ”Where is this handled?“ | the index — code cut at symbol boundaries, embedded, and searchable by meaning |
| ”What is connected to this, and what breaks if I change it?“ | the graph — typed nodes joined by typed edges |
A search hit arrives already knowing where it sits in the graph, which is the combination that makes the whole thing useful.
Applications, sources, ingests, versions
Four nouns, in this order:
Application one system
└── Sources the repositories that make it up
└── Ingest job reads them, builds the graph and the index
└── Version the result, numbered v1, v2, …One application can span several repositories, and that is the point. Cross-repo structure — service A calling service B’s endpoint, A publishing what B consumes — only exists when they are in one application together.
What it understands today
Symbols are parsed for C#, Python and TypeScript. On top of that, framework detectors recognise ASP.NET routing, EF Core, hosted services, HTTP clients, project layering, messaging, build manifests, compose infrastructure and connection strings.
A repository in another language still ingests — you get its file inventory and whatever the infrastructure detectors recognise — but with fewer symbol-level nodes, so search and impact analysis are thinner. Try one before committing to it.
Using it to modernize an existing system
The Context Graph is also the starting point when the goal isn’t to work on a legacy system but to replace it. Index the existing repository and you recover the things a rewrite actually needs:
- the data model it operates on, including the connection strings and schema the infrastructure detectors find;
- the API surface and routing, so you know what currently calls what;
- the business rules and workflows buried in the code;
- the integration points to systems that will stay.
Those become the input to a new qRaptor application — a current-architecture, Postgres-backed system with its own APIs, roles and permissions. The legacy source does not become the foundation of the new system; it is evidence about what the new one has to do.
This is understanding, not automated conversion. There is no button that turns a legacy repository into a running qRaptor application. The graph tells you what the old system does, and makes that knowledge available to agents; deciding and specifying the target system is still design work. Symbol-level coverage is best for C#, Python and TypeScript — see What it understands today.
Where to go from here
The tabs across an application follow the order of the work: ingest first, then read.
- Create an application
- Attach sources — the repositories it is made of
- Run an ingest
- Explore the graph
- Search the code
- Browse files
- Cross-repo links
- Review enrichment
- Versions & diffs
- Use it from an agent
Common issues
- Context Graph is not in my sidebar — It sits between Apps and Deployments. If it is missing, check your role.
- My repository is private — Attach a credential by name. See Attach sources.