← Back to Blog

The Institutional Knowledge Problem – What No AI Can Recover

The most dangerous knowledge on a mainframe is not in the code. It is in the heads of people who are retiring.

There is a question that comes up in almost every serious conversation about AI applied to mainframe: can AI recover the knowledge that has been lost as experienced professionals retire?

The honest answer is no – not from source code alone. And understanding why reveals something important about both the limits of AI and the urgency of a different approach.

Three types of knowledge on mainframe

Not all knowledge is the same. On a mainframe system that has been running for thirty years, there are three distinct types.

Documented knowledge. What is written down. Requirements documents, design specifications, change request records, operator runbooks. This knowledge is recoverable – it exists in files, in repositories, in email archives. AI tools can ingest it, index it, and retrieve it. It is also, in many organisations, incomplete, outdated, and scattered.

Tribal knowledge. What the team knows but has not written down. The workaround for the month-end performance problem. The reason the job runs at 2:00 AM instead of midnight. The dataset naming convention that was adopted in 2003 and never documented. This knowledge exists in the team and will survive as long as the team does – but it walks out the door when people leave.

Tacit knowledge. The deepest and most dangerous category. This is knowledge that experienced practitioners carry without being able to fully articulate it. The systems programmer who looks at a dump and knows within thirty seconds what caused it, drawing on pattern recognition built over twenty years. The COBOL developer who reads a particular calculation and knows immediately that it implements a specific regulatory requirement – not because they remember the requirement, but because they were there when it was implemented.

Tacit knowledge cannot be easily transferred even with effort and goodwill. It requires time, experience, and exposure that cannot be compressed. AI can help recover documented knowledge and some tribal knowledge. It cannot recover tacit knowledge at all.

The regulatory rule problem

The most consequential institutional knowledge on financial mainframes is regulatory. Programs that implement compliance requirements – capital adequacy calculations, risk exposure limits, reporting obligations – were written to satisfy specific regulations that existed at specific points in time.

Consider a COBOL program with this kind of paragraph:

IF WS-EXPOSURE-AMT > 250000
   MOVE 'Y' TO WS-REQUIRES-REVIEW
END-IF

What is the 250000 threshold? It might be an arbitrary business decision. It might be a regulatory capital threshold from a Basel II implementation in 2008. It might be a value that was correct when written and has not been updated to reflect later regulatory changes. It might be a value in dollars, or in thousands of dollars, or in some internal unit.

An AI tool reading this code can tell you what the code does: if the exposure amount exceeds 250000, it flags the transaction for review. It cannot tell you why that specific threshold exists, whether it is still correct, or what regulatory consequence follows from changing it. The person who knows that is the developer who implemented the original changes. If that person retired, the knowledge is gone unless it was captured.

What AI can and cannot do with this problem

In other words: AI can help you identify where the institutional knowledge gaps are most dangerous. It cannot fill those gaps.

The forcing function

The urgency of this problem is demographic. IBM estimates that a significant proportion of mainframe professionals are over fifty and will retire within the next decade. In many financial institutions, the people who built the current mainframe applications started in the 1980s and 1990s. They understand the systems at a level that cannot be replicated by reading the code.

Modernisation projects are long. A major mainframe modernisation typically takes five to ten years from initiation to completion. In many organisations, the completion date is after the retirement date of the people who understand what is being modernised.

The teams that are managing this well are the ones who have started knowledge capture before it becomes urgent. The teams that are not managing it well are discovering the gaps in production after the people who could explain them are no longer available.

Structured knowledge capture – what to do

The most valuable investment for any organisation with a mature mainframe estate is structured knowledge capture from experienced staff – before they retire. This is not free-form documentation. It is targeted interviews focused on specific programs and business rules, guided by the questions that matter most:

• Which programs would you be most nervous about if we had to migrate them without you?
• Which business rules in this codebase do you know are correct but cannot easily explain from the code alone?
• Which programs have changed significantly from their original intent, in ways that would not be obvious from reading the code?
• Which programs touch regulatory or compliance requirements that are not documented in the code or in change records?
• Are there any calculations or threshold values that depend on external context – regulatory requirements, business agreements, historical decisions – that someone new to the code would not know to question?

The answers to these questions are more valuable than any static analysis report. They are also more urgent – because the people who can answer them are retiring faster than the modernisation projects are completing.

AI can help organise, index, and query the knowledge once it is captured. It cannot generate the knowledge from source code alone. The capture must happen with human effort, while the humans who hold the knowledge are still available.

Also in this series: The Hidden Risk in Every COBOL Migration Project · Why Generic AI Tools Fail on Mainframe · What AI Can and Cannot Do with COBOL