The problem with old code
A legacy monolith is a database nobody can query. The knowledge is all there — every rule the business runs on — but it's spread across thousands of files, buried in call chains, and understood by nobody still on the team. Reading it linearly is hopeless.
The fix is to stop treating code as text and start treating it as data. If you can extract its structure into a graph, you can ask it questions.
A pipeline in passes
We built Codolith's ingestion as a multi-pass pipeline. Early passes parse the raw structure — files, classes, methods, imports. Later passes derive relationships: who calls whom, what depends on what, where the data flows. Each pass is small, testable, and adds one layer of meaning on top of the last.
Fifteen passes in, a pile of Java has become a set of structured facts: nodes with types, edges with meaning.
Why a graph
Those facts land in a Neo4j knowledge graph. A graph is the right shape because the questions are relational: what breaks if I change this method? What's the blast radius of this class? Which paths touch the payment ledger? Those are traversals, and a graph answers them in a query instead of a week of grep.
Answers you can trust
On top of the graph sit the deliverables: architecture blueprints, PDF reports, and a chat that answers questions about the codebase — and cites every claim down to file:line. The citation is the point. An AI answer about your code is worthless if you can't verify it; grounded in the graph, every answer traces back to the source.
Have something to ship?
Start with a fixed-price, two-week MVP — or scope a full build with a senior team.