The codebase nobody fully remembers

Somewhere in your company there is a solution file that opens 120 projects, and nobody alive can tell you why all 120 are there.

It works. It ships. It has paid salaries for a decade. And it has slowly crossed the line from understood to inherited. The developer who knew why OrderProcessor has three separate retry paths took that knowledge to another company. The reason the scheduler lives in its own process is a story that got shorter every time it was retold, until it became a sticky note that just says don't touch the scheduler.

You know this codebase. You might be its maintainer. There's a particular kind of care that job teaches you: you move slowly, you read twice, you keep a private map in your head of which floors creak. The map is the actual asset. It's also the thing that walks out the door with every resignation.

Memory decays. Code doesn't.

Here's the asymmetry that makes legacy software feel haunted: the humans forget, but the code never does. The three retry paths still know exactly who calls them. The scheduler still knows precisely which types it touches. Every dependency, every override, every subscription is still there, fully determined, sitting in the source.

The knowledge didn't vanish. It just stopped being legible to people.

The participant that never forgot

And here's the strange part. There is one participant in your team that re-derives the entire map, perfectly, several times a day: the compiler.

Every build, it resolves every reference, binds every call to its exact target, checks every implementation against its interface. The result is a complete, correct account of how the whole 120-project organism hangs together. It has to build that account, or it couldn't compile a single file.

Then it throws it away.

The most complete institutional memory your codebase has ever had is constructed and discarded on every build, while the humans get by on folklore and sticky notes.

Which leaves a question that, once asked, refuses to leave: what if that map were not thrown away? What if it were readily accessible, not only to the compiler, but to the other tireless reader who just joined your team: the LLM in your editor, about to plan an edit in a codebase it has never seen?

Everything the veterans took with them is still derivable. Who calls the three retry paths. What the scheduler actually touches. Why project 87 is in the solution at all. Hand the model the map, and day one starts to look like year five.

That question is the idea that got us to found GraphSlice: stop throwing the map away, and give it to the reader who needs it most.