The COBOL Problem

Estimated reading time: 5 minutes

Databases hold information. They do not pass it on.

The institution still has a working store. The people who could explain what the records mean are leaving, or already gone. What sits in the database is inventory: a list of what someone once knew, waiting for a person who is no longer in the room.

Two Stores, One Past

We had two official libraries for the same project history. Past-performance writeups: proof that the work had been done, for whom, with what outcome. Bid teams needed those records to be true. Briefers needed them to be findable. Both systems claimed to be the source of truth. They did not agree.

A title in one library was missing from the other. A contract value in one place contradicted the writeup in the second. Origin was a rumor: someone remembered a Word file, a slide, a person who had left. Leadership still pointed at “the system” as if pointing were a handoff. The stores were full. The past was still an argument.

Queries that should have been simple stacked up. A project-delivery pattern in a particular region, above a contract value, with a named result. Neither library could answer it. The work fell off one desk onto mine, then sat there while we tried to reconstruct what the systems had been hired to remember.

The team was gathering project descriptions by hand. That is the tell. When people copy titles out of a system that was supposed to hold them, you are watching transfer fail in real time. The database still runs. The handoff never happened.

The Baseline the Database Could Not Produce

I stopped treating either database as the handoff.

I pulled a baseline from the source documents themselves: project writeups, a set someone had already trusted, published case studies. I stopped at the first hundred to see whether the pattern held. It did. Duplicate titles. Missing outcomes. Claims with no origin. Records that could not survive a skeptical reader, let alone a new teammate who had never met the person who shipped the work.

The live library was already in the hundreds and climbing toward a hard ceiling. Adding another field, another view, another “single source of truth” would have grown the same unread pile. The problem was upstream of the interface.

Each record needed a review status and a clear origin. A new file format does not create those. Someone has to assign them, defend them, and refuse to publish a title that cannot point back to a source. Without those two fields, a new store is another warehouse for the same unread history.

The work in front of us was curation. Someone had to sit between the person who knew the project and the record that was supposed to outlive them.

What COBOL Actually Named

IT already has a name for this shape, even if it usually applies the name to code.

A COBOL system can run for decades. Payroll still posts. Claims still process. The institution’s logic lives in the programs. The people who could explain or change those programs have retired. You still have a working store. You no longer have a transfer path. Consultants get hired to read the code the way archaeologists read a ruin: the system functions, and almost nobody can say why.

That is the original COBOL problem. The program did not fail. The interpreters left.

Knowledge as Code asked whether memory survives a tool change. This is the next failure: the tool never had to change. The store is still there. Transfer never happened.

I call the knowledge analogue The COBOL Problem. Databases, document libraries, and “sources of truth” hold records the way those systems hold programs. They do not pass meaning on. Without a curator between the contributor and the record, institutional knowledge dies in place: fully stored, unusable as a handoff.

The COBOL Problem is not a language-migration thesis. It is a knowledge pattern. You can rewrite every COBOL module and still have the same failure in your project history, your wiki, and the corpus you are about to hand to an agent.

Three Jobs Between Contributor and Record

A curator does three jobs. None of them is “stand up a better database.”

Reconcile. When two stores claim the same past, name the mismatches. Write down which record wins, why, and what remains unresolved. Silent merges manufacture confidence. Named contradictions preserve a path back to the evidence.

Annotate. Every record carries origin and review status. A title with no source is inventory. A title with a source, a reviewer, and a date can travel. The annotation is the difference between a row you can cite and a row you can only hope is true.

Hand off. The test is whether a new person, or a new agent session, can use the record without calling the person who wrote it. If the answer depends on a hallway conversation, you still have a COBOL problem. The store is running. The interpreter is the system.

Negative Knowledge is adjacent: what to keep when a claim turns out wrong. The COBOL Problem is prior. It asks whether anyone sits between the contributor and the file at all. A retrieval layer over the old dump, a wiki migration, a markdown repo without those three jobs repeats the pattern in a cleaner folder. The agent will sound fluent. It will still be reading a ruin.

The next store will not save you. A named curator might.

Who is the last person who can still explain your most important database?

Madam I’m Adam

This continues the thread from Knowledge as Code and Negative Knowledge: portable files, then annotated retirement, then the missing role that makes both of them inert.