The modernized code compiled. Passed every unit test. Then it corrupted a bank account on the first live wire transfer. The tests couldn't see this. The field holding a transfer limit, TRN-LIMIT, was a COMP-3 packed decimal defined three copybooks away from the rewrite. Which reading of those bytes was live got decided by a flag set in a different program, sequenced by a JCL batch job that fires at 2 a.m. None of that lives in the one file a translator reads. So the model saw a number, wrote a plain long integer, and mangled the bytes into the accounts table. That's not a bad translation. It's contextual blindness. The one fact that mattered was invisible in a single-file window, and a bigger model won't fix it: a codebase of millions of lines never fits in any window. So we built CodeGraph to map the estate before touching a line. On our synthetic wire-transfer fixture it recovers 9 of 9 dependencies for that change, with file:line provenance, against 3 of 9 for a single-file view, and names the 6 the text tool missed. The map is the product. Translation is the downstream job. (The bank and those numbers are a handcrafted demo estate, so the dependency set is known and 9/9 is a measurement, not a slogan.) If you're modernizing a mainframe: does your tooling prove which dependencies it pulled before it rewrites anything, or does it trust the one file on screen? Curious how teams draw that line. #COBOL #LegacyModernization #Mainframe #KnowledgeGraph