Foundational Brings Deterministic Data Lineage and Code Analysis to COBOL and Mainframe

We are announcing something that's quite special to me today: Foundational now officially supports automated, deterministic data lineage across COBOL, JCL, Copybooks,  DB2, and other Mainframe technologies. While we've been doing this for quite a while, in the past year the level of maturity, accuracy, and scale of our ability to analyze legacy code and in particular mainframe related technologies has leapfrogged. With this update, we are bringing the mainframe into the same continuously updated data and code graph as the rest of the enterprise, from source applications and batch processes to cloud platforms, dashboards, models, and AI systems.

Ironically, in the past year the world has seen how AI lowered the cost of explaining, generating, and debugging code. However, in large-scale environments and in particular ones with complex legacy code, understanding what the existing system does with a high degree of accuracy does not work well. At all. It's slow, expensive, and prone to errors. Worse, AI doesn't tell you where those errors are. And maybe even worse than that, it makes everyone excited to still try!

When a global bank needs to modernize an old application containing dozens and sometimes hundreds of repositories, it needs to know which data it reads, how that data is transformed, where it is written, and what will be affected when the system changes. Nowhere is that challenge more consequential than on the mainframe.

Mainframe applications continue to run critical transaction processing, financial operations, customer records, risk calculations, and regulatory reporting for many of the world's largest organizations. The data produced by those applications no longer stays on the mainframe. It flows into cloud data platforms, operational services, analytics, reporting, machine-learning models, and, increasingly, AI applications.

With this release, Foundational becomes, to our knowledge, the first fully automated lineage and data graph system for COBOL-based applications.

‍

The Mainframe Blind Spot

Most data and code lineage systems begin their analysis inside a database, warehouse, or cloud platform. They attempt to inspect query logs, metadata, and runtime activity to infer relationships between tables and columns.

That approach can be useful, but it starts too late. By the time mainframe-derived data reaches a cloud warehouse, the most important transformations may have already happened. Fields may have been read from shared record structures, validated against business rules, reformatted, aggregated, conditionally written, passed between programs, extracted by batch jobs, or loaded into DB2.

A database log might show that a table was queried. It cannot necessarily explain the COBOL calculation that produced a value, the JCL that connected a program to a physical data asset, or the chain of application logic that moved a field from a system of record into a downstream report.

For years, organizations have addressed this gap through manual analysis and specialized work. Teams of specialists interview application owners, inspect programs, document dependencies, and assemble lineage diagrams through months of professional services work. That work is expensive, difficult to repeat, and almost immediately at risk of becoming outdated.

More recently, AI-based approaches have made it easier to summarize individual programs and answer questions about selected sections of code. This is valuable for exploration, but enterprise lineage requires something different. It requires consistent analysis across millions of lines of code, dependencies distributed across hundreds of repositories, and evidence precise enough to support governance, modernization, and production change.

A high-level explanation of a COBOL program is not the same thing as a complete, field-level data graph.

Why Mainframe Lineage Is Difficult

Mainframe lineage is not simply parsing some COBOL. A COBOL program rarely contains everything required to understand its behavior. Data structures may be defined in Copybooks and shared across many programs. A field may be reinterpreted through overlapping representations. There is occasionally SQL in the application. The name used by a program may only be connected to an actual data object when the corresponding JCL is evaluated.

Even after a single program is understood, its dependencies may cross application boundaries and repositories. COBOL might be owned by one team, Copybooks by another, JCL by an operations group, and DB2 definitions by a database team. Downstream consumers may be written in Java, Python, SQL, Scala, or another language entirely.

Names alone are not enough to connect these systems accurately. Two similarly named fields may have no relationship. The same data asset may be referenced differently by separate programs. A transformation may involve several intermediate fields and conditional code paths before a final value is written.

The analyzer must also distinguish between data flow and control flow. A field used in a calculation contributes data to the result. A field used in a condition may only determine whether the calculation runs. Treating both as equivalent creates a graph full of relationships that are not real data provenance.

Solving this accurately requires semantic understanding: resolving symbols, modeling storage, expanding shared definitions, following transformations, interpreting orchestration, and linking independently analyzed components into one consistent representation of the system.

Expanding Our Compiler Into the Mainframe

Foundational approaches this problem using a deterministic code-analysis engine modeled after a compiler toolchain.

The first stage acts as a compiler. It parses source code into a structured representation, resolves fields and symbols, expands Copybooks, understands COBOL data structures, analyzes embedded SQL, and traces data from read sources through transformations to write destinations.

The engine does not stop after finding that two field names appear in the same program. It determines how values move between those fields, what calculations are applied, and under which conditions a transformation occurs.

The result is field-level lineage backed by exact source-code evidence.

The second stage acts as a linker. Industry veterans would often call this "stitching." Each repository can be analyzed independently, producing a lineage snapshot together with references that cannot yet be resolved locally. The linker then connects those snapshots across repositories, resolves external definitions, normalizes different references to the same asset, and produces one consistent enterprise data graph.

This compiler-linker architecture is also what allows Foundational to operate at enterprise scale. Rather than placing an entire application estate inside an AI context window or repeatedly analyzing the same code, Foundational analyzes each repository deeply and then resolves the global relationships in a separate, purpose-built phase.

‍

Knowledge Built Through Reverse Engineering

Building this engine required more than adding COBOL grammar to an existing parser.

Our roots in cybersecurity and specifically in reverse engineering have brought us to this stage, and those disciplines shape how we approach code analysis.

In reverse engineering, you cannot assume that the name of a component accurately describes its behavior. You reconstruct that behavior from evidence. You follow memory and data movement, resolve indirect references, model execution semantics, and preserve the connection between every conclusion and the source that supports it. We applied those concepts to COBOL parsing.

Over time, our team developed deep, specialized knowledge of COBOL data semantics, application structure, batch orchestration, and the ways real mainframe environments differ from simplified examples. That knowledge is encoded into Foundational's analysis engine rather than depending on a specialist to rediscover the same relationships for every customer.

This background is also why Foundational is designed to analyze source code without requiring access to sensitive production data. The system derives its graph from code and metadata, an architectural principle rooted in our approach to security.

What Deterministic Means for Accuracy and Token Use

Generative AI is exceptionally useful for exploring unfamiliar code, creating documentation, and accelerating modernization work. We expect it to become a standard part of how enterprises maintain and transform mainframe applications.

But AI-generated interpretation and deterministic analysis is not good enough for enterprise-scale code writing or code auditing. By default, all the LLMs work with text-based grep searches, which for large codebases is slow and expensive. Language Server Protocol (LSP) improves this, but it's still text search, just faster. It can't tell, for example, if data is being read or written, nor can it trace a dataset name dynamically constructed by a JCL job used in a completely different repository. For this to "work," you need to build a graph.

Foundational's analysis is also reproducible: the same code and configuration produce the same graph. Each relationship can be inspected and traced back to the relevant source. When the engine cannot resolve a dependency, that dependency can be surfaced explicitly rather than completed with a guess that is hard to identify. The output is repeatable, inspectable, and grounded. That distinction is important at scale, and not just for mainframe.

How This Is Really Useful to AI

The AI era makes deterministic lineage even more important. First and foremost, more and more AI systems now consume data that first originated in mainframe applications. A model, agent, or automated decision may depend on a customer attribute or financial calculation whose history began inside COBOL. If lineage begins only after that data reaches the cloud, the organization does not have complete provenance.

But even more importantly, AI modernization tools need a strong harness and a continuous feed of reliable context. For that, AI must understand what the original code does, which downstream systems depend on it, and what behavior the replacement must preserve.

Lastly, AI is increasing the velocity of software changes. Teams generate dramatically more code, and it has become far easier and far more popular to bring multiple AI IDEs into the enterprise. That increase in change velocity increases the need for accurate impact analysis, validation, and governance. Our code and CI checks, which leverage the deterministic data graph, provide those controls.

From Systems of Record to Systems of Intelligence

With mainframe support, Foundational gives enterprises one continuously updated view of data across systems that were previously analyzed separately. Modernization tools can deeply understand existing behavior before deciding what to rehost, refactor, rewrite, or retire. Engineering teams can identify the potential blast radius of a change before it reaches production. Data and governance teams can trace critical fields across application logic, batch processes, databases, cloud platforms, and reporting systems.

The mainframe does not need to become a black box simply because the people who built it are retiring, the documentation is incomplete, or the code predates the modern data stack. It can be analyzed with the same rigor as any other mission-critical software system.

Assess Your Mainframe Lineage

Foundational now supports automated lineage across COBOL, JCL, Copybooks, and DB2, connected to the wider enterprise data graph.

For organizations evaluating lineage, governance, or modernization approaches, we are offering a Mainframe Lineage Assessment. The assessment applies Foundational to a representative portion of your application estate and evaluates:

• The field-level relationships that can be reconstructed automatically
• The transformation evidence available for each relationship
• Dependencies distributed across programs and repositories
• Connections between mainframe applications and downstream systems
• Areas where existing lineage or AI-based analysis loses accuracy as complexity increases

To learn more, reach out to Foundational.