"What calls charge_card?" isn't a search — it's a graph traversal. Graphify parses every file into a syntax tree, walks it to emit nodes (functions, classes, imports) and edges (calls, imports, uses), then tries to resolve each call site to its definition — and labels every edge by how sure it is. The honesty is the whole point.
loading…
A file flows in. tree-sitter parses it into a concrete syntax tree — purely from the text, no model, no network. The walker emits a node per definition and an edge per relationship. The call-graph pass then guesses which edges connect to which — and tags each one.
The whole graph is just a list of nodes (the things) and edges (the relationships between them). The pipeline is a flat, stateless chain — each stage hands plain data to the next. Hover the stages to see what each one adds.
That's it. Everything else — the interactive viz, the Neo4j export, the MCP server a team queries over HTTP — is downstream of this minimal schema. The one field that makes Graphify honest is confidence, which rides on every edge.
tree-sitter is a rule-based parser. It does not resolve names, types, or build a symbol table — it captures structure exactly as written. So it can tell you "there is a call expression whose callee is the identifier foo at line 42" — but never which foo. Click a line and watch its syntax tree light up.
Notice line 4: the tree records a call_expression with callee charge_card — but the import on line 1 means it might be the imported one, or a local shadow. The tree can't say. That unresolved question is exactly where the next stage earns the INFERRED tag.
First pass collects the easy facts — imports, same-scope calls — as EXTRACTED edges. The second pass walks every call site and tries to connect it to a definition by name-matching. Step through the code and watch each edge get drawn — and tagged.
The second pass is a heuristic, not a proof. A unique name match → INFERRED. A method call on an object whose type is unknown, or a name with two matching definitions → AMBIGUOUS, listed in GRAPH_REPORT.md for a human.
Instead of pretending the graph is ground truth, each edge says how it was found. That lets a consumer filter by confidence — a "prove it" view shows only EXTRACTED; turn on INFERRED for recall. Toggle the tiers and watch a real graph thin out and fill in.
Drop INFERRED + AMBIGUOUS and you're left with the provable skeleton — imports and unmissable same-scope calls. Add them back and the graph fills in, but now some edges are candidates. Same graph, two honesty settings.
The non-code layer (PDFs, images, video) has no AST, so an LLM extracts its edges — those are INFERRED by construction. The deterministic and probabilistic layers never get confused, because the tag travels on every edge.
| Tier | Means | Comes from | How to read it |
|---|---|---|---|
| EXTRACTED | explicitly in the source | an import statement, a direct call | trust it — it's a parse fact |
| INFERRED | a reasonable deduction | call-graph 2nd pass, context co-occurrence, the LLM media layer | treat as a candidate; grep to confirm |
| AMBIGUOUS | uncertain | multiple matches, dynamic dispatch, unknown type | flagged for human review |
Resolving a call site to the definition is a hard static-analysis problem — and in dynamic languages, often impossible from syntax alone. The literature is blunt about it. Step through the cases a name-match pass simply can't crack.
Which class's .save()? Without knowing obj's type, syntax can't say. Becomes AMBIGUOUS or is missed.
Function pointers, getattr(x, name)(), monkeypatching, dependency injection — the callee isn't even a literal name in the source.
The same entity can appear as two nodes ("ghost duplicates"), auto-merged at build time — so even node dedup is heuristic.
PyCG, the precision-leading academic Python tool, hits ~99% precision but only ~70% recall — and runs out of memory or time on programs past ~2,000 lines. JARVIS trades heavyweight flow-sensitive type inference for more recall.
A tree-sitter name-match pass is far simpler than PyCG. So its resolved edges are best read as candidates — which is precisely why Graphify tags them INFERRED, not EXTRACTED. Honesty over false precision.
Atlas — OpenAlice's cron-refreshed code & knowledge graph — is exactly this idea at org scale. Its call-graph hook is, verbatim, the plan to "steal Graphify's AST call-graph". The mapping is one-to-one.
Atlas resolves only ~15–19% of call edges; the rest are external/ambiguous. That isn't a defect to hide — it's the same reality PyCG's 70% recall and Graphify's three-tier model describe. The standing rule: filter call-graph queries by confidence, then grep to confirm the gaps.
The determinism boundary matches too: Atlas's symbol / import index is the EXTRACTED layer (exact, from parsing); semantic search (pgvector) is the INFERRED / concept layer — the same split Graphify draws between tree-sitter and its LLM pass.
Because resolution is candidate-grade, both tools converge on the same advice: query the graph first, fall back to grep for the gaps. A query returns EXTRACTED edges instantly and INFERRED edges as leads — and where the graph is silent, you grep. The graph doesn't replace search; it tells you where search is and isn't needed.
The upgrade path, if you ever harden resolution beyond name-matching, is the PyCG / JARVIS direction: per-function flow-sensitive type inference. It buys recall at a steep scaling cost — worth knowing before you promise anyone a "full call graph."
Parse to a syntax tree, walk it into nodes and edges, resolve the call sites you can, and tag every edge by how sure you are. You saw the second pass run live, watched the confidence tiers filter a real graph, and learned why "static call-graph" and "candidate-grade" mean the same thing. You now read a code graph the way Atlas does.
A graph is structured memory about code. Now let an LLM keep a whole knowledge base fresh — the same provenance discipline, applied to prose.