Every large company running old business systems has the same quiet liability: batch jobs, reports, and billing scripts built up over years by people who’ve long since left, with nobody holding a single reliable picture of what any of it actually does, why it exists, or what it touches. The knowledge lives in three unreliable places — code nobody wants to read, documentation that may already be stale, and people’s memories. When a business stakeholder asks “what happens when an account’s credit limit is exceeded, and which tables get touched?”, the honest answer today is: go find a developer and hope they remember, or go read the code yourself.

I built Graphify against exactly that situation on a real legacy codebase: ~152 components, mixed Java/bash/PL-SQL, with existing but scattered documentation of varying quality. The goal wasn’t another wiki that goes stale the moment it’s written — it was a system that keeps the human-written business intent tied to the actual, mechanically-verified code structure, so an answer can be traced back to something real instead of an LLM’s guess.

Graphify is a pipeline, not a chat app with a search box bolted on. It parses the real source with Tree-sitter into a deterministic “wiring diagram” first — no AI involved at this stage — producing a structural graph of what calls what, what reads/writes which database table, and which scripts depend on which (on the pilot codebase: ~11,800 nodes, ~30,000 edges, covering Java classes, bash scripts, PL/SQL packages/procedures, and DB tables). That graph is rendered as an interactive HTML view (vis-network) you can filter by component, edge type, or schema, and a coverage diagnostic flags nodes the parser likely missed something on.

On top of that mechanical layer, it ingests the humans’ functional and technical write-ups for each component and aligns each one to its matching code node — a matching pass that isn’t naive string-matching: it caught two real bugs where it would have silently merged two different components’ descriptions together, and correctly flagged the genuinely ambiguous cases instead of guessing. A ~1,600-term business glossary built from an existing spreadsheet keeps English-authored content and Italian ingestion terminologically consistent, since the whole system is bilingual (authored in English, queried in Italian) by design. All of that — code graph, functional descriptions, technical descriptions, business-process docs, glossary — gets merged into one integrated graph and indexed into a pgvector-backed search store (5,085 searchable chunks in the pilot run).

The actual “product” a user touches is a live Claude Code session: you type a business question in Italian — “what does the billing-frequency-change process do, and what tables does it touch?” — and the session classifies the question type (a structural fact, an end-to-end process, a fuzzy/semantic question, or a term definition), routes it to the right source (a graph lookup, a vector search, or the glossary), and writes back a structured Italian answer that names its sources and states its confidence, rather than inventing an answer not backed by what was actually retrieved. No dashboard to learn, no code to open.

The hard part of this kind of system was never “can an LLM summarize code” — it was keeping four independently-produced layers (mechanical graph, functional docs, technical docs, business docs) honestly aligned to each other without letting any layer quietly overwrite or corrupt another as new documents landed in batches. I ended up needing strict rules about which pipeline steps are allowed to be read-only versus which are allowed to update a file in place, and a documented re-run order, because getting that wrong is exactly the kind of failure that’s invisible until someone asks a question and gets a plausible-sounding but wrong answer. The bugs the alignment pass caught — cases that would have silently mixed up two different components — are the reason I don’t trust “the LLM just merges it” as a step in a system meant to be a source of truth; every merge needed a deterministic check with an explicit “ambiguous, don’t guess” escape hatch.

The near-term gap is answering “has this process changed since the docs were written?” — drift detection between what the documentation claims and what the code now actually does, which matters a lot in any org where code and docs update on different clocks and nobody notices the divergence until an incident. The same pattern generalizes well past this one codebase: any enterprise sitting on a large body of legacy or loosely-documented internal systems — a mainframe migration, an M&A integration where two codebases and two sets of institutional knowledge need reconciling, a compliance team that needs to prove which systems touch which data — has the same underlying problem of tribal knowledge trapped in code and heads. The architecture doesn’t assume Java/bash/PL-SQL specifically; the Tree-sitter layer is swappable per stack, and the alignment/graph/query layers on top are language-and-domain agnostic. A natural next audience beyond business stakeholders is architects and developers themselves, querying the same graph for “what would break if I change this.”