Legacy modernization · deterministic · bring your own model

You inherited a system the business has run for forty years, and the map left with the people who wrote it.

Before you change a line, you need to know what you are holding. Which programs everything else depends on. Where the data layer is. Which modules are still live and which are dead. Which era each part was written in. doloop reads all of that from the code itself, in one pass, with no model and nothing leaving your machine. The first scan is free, and it also tells you how much of this your particular system will give up.

Step one · see it

Make the system navigable before you touch it

A legacy system carries its own structure whether or not anyone wrote it down. doloop reads that structure straight from the code, in a single pass, and hands you a map of the system you are about to change. No model runs and no source leaves your machine. The map shows you:

LOAD-BEARING PROGRAMS · DO NOT BREAK · RANKED BY FAN-IN (HOW MANY PROGRAMS CALL IT) GOLGE 28 SICPEN 10 DEPSEC 9 AYAR 4 PLASSEC 3 68 PROGRAMS · 90 CALL EDGES · 8 ENTRY POINTS · 7 LEAF ROUTINES · 25 TO TRIAGE TRIAGE = DYNAMICALLY-REACHED OR STANDALONE, FOR REVIEW (NOT A DEAD-CODE CLAIM)
Fig. M3 the first scan ranks the programs everything else depends on, so a team knows what not to break before reading a line of logic fikopar is the modular case (rich call graph); on a monolithic system the map falls back to thinner module and convention navigation, and the first scan tells you which kind yours is fikopar, a real undocumented Turkish ERP, 68 programs, call graph read in one pass; fan-in reproduces from a published command · cite and reproduce at doloop.io/research

How much the map shows depends on how your system is built

A system whose programs call each other has a rich call graph, and the map reads it deeply: the dependency hubs, the layers, the dead ends. A system whose programs are each launched on their own and do not call each other has little call graph to read, and the map falls back to navigating by module, by convention, and by copybook. You do not have to know in advance which kind you have. The first scan tells you, and learning that your system is one kind or the other is itself a fact about it you can use.

The map shows you where everything is and how it connects. It does not tell you what any program computes. It is an index, not a summary. Reading that one program is called by thirty others tells you it is load-bearing, not what it decides.

One real forty-year system, read as its eras

A legacy system is rarely written all at once. doloop reads each module on its own, so a system that grew over decades shows up as the layers it actually is. The old business ledgers hold the convention of their era, a later-migrated module sits between conventions, and where a module never settled on one way of doing things the gate stays silent rather than guess.

ACAS MODULES BY SCOPE-TERMINATION ERA (END-IF %) · ONE SYSTEM, MANY VINTAGES SILENCE ZONE 30-70% (UNSETTLED, GATE OWES SILENCE) 0% · PERIOD (LEGACY ERA) 100% · END-IF (MODERN ERA) 30 70 FLOOR general 4 purchase 10 irs 19 sales 23 stock 35 payroll 63 common 72
Fig. M4 one system carries several eras at once: the old business ledgers hold the period convention, the later-migrated payroll sits unsettled, and the modern common layer has settled on END-IF, so the gate reads per module and owes silence where a module has not settled ACAS, real 40-year accounting ERP, about 474 programs; per-module END-IF over IF statements; numbers re-derive from canonical SVN HEAD r78 · cite and reproduce at doloop.io/research

Step two · gate the change

The AI rewrite compiles, passes the tests, and breaks a rule no one wrote down

Once the system is navigable, the modernization begins, and most of it will be written by an AI tool trained on modern code. It builds clean and the tests go green. It also writes the code the way modern systems do, not the way this one has always done it, and the people who would have caught that in review retired years ago. doloop reads the conventions the system already keeps, from its own code, and flags the change that breaks them, with the same verdict on every run and the line and the rule behind it.

The failure tests cannot see

A modernization that preserves behavior on every tested path can still violate a convention the system holds everywhere. The convention was never written in a rulebook. It lives only in the code, in how the system has always done a thing, which is the one place a fixed linter does not look and a generic model does not know to respect.

AI rewrites a legacy COBOL module ✓ compiles clean ✓ tests pass the break is invisible here this system ends every IF with IF DUE = 0 GO TO SKIP. the AI wrote it the modern way IF DUE = 0 ... END-IF doloop FLAGS no rule was written down. doloop reads the convention from the system's own code and cites the rule, the line, and the rate.
Fig. M1 a rewrite can preserve behavior on every tested path and still break a convention the system holds everywhere the catch runs against the system's own inferred convention

The proof: the same statement, opposite verdicts

Each house's rule is inferred from its own code, never hardcoded. A modern AWS reference system (carddemo) ends an IF with the explicit END-IF keyword, on 98% of its IF statements, more than a thousand of them. A deep-legacy system ends it with a bare period, in the pre-1985 dialect. Drop one system's statement into the other and the verdict flips.

LEGACY HOUSE period law, near 100% MODERN HOUSE carddemo, END-IF on 98% of 1,059 IFs legacy period-IF modern END-IF PASS FLAG FLAG PASS
Fig. M2 each statement passes in its own house and flags in the other; the verdict follows the house, inferred from its own code 525/525 leave-one-out, 7 houses, two independent 1980s corpora, verified 3 ways: tokenizer, GnuCOBOL, ANTLR AST · cite and reproduce at doloop.io/research

The legacy convention is not one cherry-picked system. Two independent 1980s corpora, a national-insurance government system and the United States NIST COBOL-85 conformance suite, hold the bare-period rule at near 100%, with no shared authorship. The same convention reproduces out of sample on two real, independently authored business systems we did not choose in advance, a Turkish accounting ERP and a Brazilian point-of-sale system, each holding the bare-period rule under leave-one-out. The split holds under leave-one-out on 525 of 525 held-out programs across seven houses, and the convention is verified three independent ways: a column-aware tokenizer, the GnuCOBOL compiler front-end, and a full ANTLR COBOL-85 syntax tree.

What this is, and what it is not

doloop is a deterministic gate on the AI's modernization. It reads how the system is written, its conventions, and flags an AI rewrite that breaks them. It runs on every change, returns the same verdict every run, and cites the rule, the line, and the rate behind every flag, so a verdict can be replayed and audited rather than taken on trust.

Stated plainly, so it can be trusted:

It checks conventions, not business rules. It catches when an AI rewrite breaks the system's own way of doing things. It does not extract what the code means or what a rule decides. Reading that this system ends IFs with periods tells you nothing about what the IF decides.

It is a coherence gate, not a comprehension tool. It tells you where the system is structured, which makes the legacy easier to navigate, but it does not claim to understand the logic.

Honest about where it stands

The transplant above shows the engine can infer a system's conventions and gate an AI rewrite against them. The number it does not yet have on COBOL is the one only your codebase can produce: the false-block rate, the share of flags your own reviewers would overturn. That number has exactly one requirement, and we learned it by trying to measure it without you and failing. It needs accept and reject decisions made by reviewers other than the author, on the modules that have settled on a convention. A solo open-source project cannot provide that, because one person accepting their own drift is not a review, and the gate flagging that drift is arguably right, not wrong. Your codebase can provide it, because your changes are reviewed by someone other than the person who wrote them. That is the one input that produces the number, and it is the reason the number has to be measured on your system rather than ours.

That is what a design partnership is for. The demonstration is ready now. The precision number on your system is the first thing we measure together, on your code, on your machine, where your source never leaves it.

Become a design partner

We are taking on a small number of teams modernizing their own legacy systems. It starts with the free first scan, the map of your system and how much call-graph structure it holds. From there, together we measure whether the gate catches the convention breaks your reviewers would reject, on your code, on your machine. Your source never leaves it. Bring your own model.