.png&w=256&q=75)
🤝 Top Collaborators
.png&w=640&q=75)
🤓 Latest Submissions
COBOLogist — Legacy Provenance Engine
Legacy modernization projects COBOL migrations being the canonical example are almost always judged by one bar: does the translated code compile and pass basic tests? That bar is dangerously low. Decades-old codebases encode undocumented business logic — a grace-period rule added after a fraud incident, a state-specific carve-out negotiated in a legal settlement nobody can locate anymore. The engineers who wrote those rules have retired. The comments, where they exist, describe what the code does, never why. Existing tooling attacks the translation problem, not the understanding problem. Compiler-upgrade advisors validate that modernized code behaves identically to legacy code on synthetic inputs. Natural-language code explainers describe what a paragraph of COBOL does in plain English. Symbolic-execution test generators synthesize test cases that exercise branches. None of them tell you why a rule exists, what real-world evidence there is that it ever mattered, or whether it's safe to drop before you translate. COBOLogist is a four-stage pipeline that answers those questions systematically. Stage 1 performs deterministic static analysis on the legacy source, parsing it into a structured rule table — each row a condition, an action, and an exact source location. No model judgment is involved. Stage 2 searches available documentation — change requests, comments, legal memos — and tags each rule Documented, Inferred, or Unknown; this is the one stage where an LLM's fuzzy judgment is trusted, because a wrong guess is low-stakes and reviewer-checkable. Stage 3 replays real historical transaction logs against every rule, counting how often it actually fired in production — pure computation, no model involved. Stage 4 runs legacy and modernized code against the same historical data, diffs the outputs field by field, and joins every mismatch to its provenance tag and firing frequency. The diff itself is an exact comparison, never delegated to a model; an LLM only writes the plain-English narrative explaining why a divergence matters. The output is a single ranked report whose value fits in one line: "Rule diverges. No documentation found. Fired 12 times in 5 years, all approved." That sentence — not a green checkmark — is what a migration team actually needs before sign-off. It doesn't just flag a bug; it tells you the rule has real production history and no paper trail, and forces the question: was dropping it intentional? Target users are engineering teams and technical leads running legacy-to-modern migrations — banking, insurance, and government systems still running COBOL, RPG, or PL/I cores. They'd run the pipeline against their legacy source, a documentation corpus, and historical transaction logs before greenlighting a translated codebase, using the ranked report as a pre-flight gate rather than a leap of faith. What makes it unique is the architectural discipline: deterministic core, LLM only at the edges. Every safety-critical decision — rule extraction, the actual diff — stays boring and auditable. The LLM's two jobs (fuzzy document matching, narration) always ship with their raw evidence alongside the judgment, so a human can verify or overrule rather than trust blindly.
27 Sep 2026
