Toggle to a single-file view and six of the nine dependencies behind one wire transfer vanish from the screen. That is the whole bug in mainframe modernization, made visible in one click. When we built CodeGraph, we handed the same COBOL change to two retrieval methods over a synthetic bank fixture. A single-file context window, the way most AI tools read code, recovered 3 of the 9 dependencies that actually govern the change. The repository-aware knowledge graph recovered all 9, each edge carrying its own file and line. The six that vanish are the ones that corrupt a database. TRN-LIMIT is a COMP-3 packed decimal, so it maps to BigDecimal, not long. A REDEFINES lets the same six bytes be read as text. A flag that decides which reading is live gets set in a different program. And a 2 a.m. JCL job sequences the whole thing. None of that lives in the file where the change is made. Hand a model only the three visible facts and it emits long TRN_LIMIT, writes corrupted bytes into the ACCOUNTS table, and passes every unit test on the way to failing in UAT. CodeGraph is not a COBOL-to-Java translator. It is the map you build before touching a single line, so the retrieval layer can actually see what a change reaches. The 9/9 versus 3/9 result is measured on that shipped synthetic wire-transfer fixture, where the true dependency set is known by construction. That is what makes it a measurement, not a claim. 🔍 If your team is weighing a modernization, one question is worth sitting with. Of all the dependencies behind your last risky change, how many do you think your current tools actually saw? We would genuinely like to hear how you are thinking about it. #COBOL #MainframeModernization #GraphRAG #DORA #TechnicalDebt