Most of what an organization understands about itself lives in people, and it leaves when they do. Documentation goes stale the day it is written. We study what it would take for a system to hold that knowledge and keep it current.
Spend time in any long-running operation and you meet the person everyone goes to. The one who knows why that valve is plumbed backward, which alarm to ignore, what the previous integrator was thinking when they wrote that routine. That person is the operation's real memory. They are also a single point of failure, and when they retire or move on, a large part of how the place works walks out the door with them.
This is the problem behind our Knowledge and Memory research. Most of what an organization understands about itself is not written down anywhere useful. It lives in people, informally, and it decays.
Documentation Decays the Day It Is Written
The standard answer is "document it." In practice, documentation captures a snapshot of intent at one moment and then begins drifting from reality immediately. The system gets modified, the workaround gets added, the parameter gets retuned, and almost none of that makes it back into the document. Six months later the documentation describes a system that no longer exists, which is worse than no documentation, because people trust it.
Inherited control code is the clearest example. A routine written years ago, copied to a new line, tweaked under pressure during a commissioning crunch, and never fully re-reviewed. The logic runs. What it is actually doing, and why, lives in the head of whoever last touched it, if they are still around. The code is present. The knowledge of the code has decayed.
The Decay Is Invisible Until It Is Expensive
The insidious thing about knowledge decay is that nothing breaks while the knowledgeable people are still there. They quietly compensate. They know which discrepancies are real, which alarms are noise, which procedures are out of date. The operation runs smoothly precisely because a few people are continuously applying knowledge that exists nowhere but in them.
An operation can look completely healthy and be one resignation away from losing how it works. The cost of decayed knowledge is hidden until exactly the moment you can no longer afford it.
You see the bill come due during a personnel change, an audit, or an incident, when suddenly the informal knowledge is needed and the person who held it is gone. Then the team spends weeks reconstructing what used to be instant, and often gets it wrong.
Holding Knowledge in a System That Stays Current
The research question is whether a system can retain operational knowledge as it is created and keep it current, so what a team learns once stays useful to everyone who comes after. Not a document that is true on the day it is written and stale thereafter, but a living model that updates as the operation changes.
That is harder than it sounds, because the requirement is not storage, it is currency. A knowledge store that does not update is just slower-decaying documentation. The interesting version reads the operation continuously, so that when the logic changes or a new workaround appears, the model reflects it rather than describing the system as it was. In one field study, a reconciliation system we built surfaced discrepancies that a few experienced people had been silently correcting for months. The knowledge to catch them existed, but only informally and only when those people were paying attention. Once the system held it, it was applied every time.
Why This Is a Research Direction, Not a Product Feature
It would be easy to treat this as a documentation tool. We think that misses the point. The goal is not to write better documents. It is to change where operational knowledge lives, from fragile and personal to held by a system that keeps it current. That is the direction behind Atlas, our research into a living model of how an operation runs.
An operation that loses its knowledge every time someone leaves is rebuilding its own understanding over and over. We think that is a solvable problem, and solving it is worth more than almost any single prediction a model could make, because it changes whether the operation gets to keep what it learns.