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.
What follows is the anatomy of that decay as we have actually run into it on live sites, because the failure has a shape, and the shape is more useful than the sentiment.
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 artifacts an engineering team keeps under version control decay slowest, and they are usually not the artifacts that decide behavior. When a merge point started releasing product in slugs instead of its configured ratio, the gating routine was diffed against its reviewed source of record and came back identical, which cleared an entire category of cause in minutes. What eventually turned out to be wrong was a runtime timeout, raised later from 150 ms to 1000 ms so that normal gaps between cartons stopped tripping a starvation override. That value was never in the reviewed source. It was retuned in production with no download, which is how plant floors work, and it is exactly the class of fact that no document ever catches up to.
Even the export can be stale about itself. The same file that carried the correct logic carried tag values from the project file's last offline save, showing a starvation override active when the running controller said it was inactive. A document that is confidently wrong is the format decay prefers.
The Names Outlive the Things They Name
Decay is easiest to see in references, because references survive their referents.
An operator once copied four faulted tag names off a supervisory screen and asked why all four zones were down. None of those names existed in the controller. They were display aliases mapped years earlier by somebody else, pointing at a zone fault word. The mapping still worked. The knowledge of what it mapped to was gone, and reconstructing it was the first work of the session.
The deeper version is a reference to something that stopped executing. On another line, a conveyor element flashed red permanently against a data point the running system no longer maintains. The jam-reset blocks it pointed at were still declared in controller scope with the right type and never executed by any instruction call. Their one remaining reference was read-only, inside a roll-up that sums jam latches. Declared but never driven, referenced only in a roll-up, is the signature of a dead thing, and you cannot tell it apart from a live one by searching for the tag name. Both look identical from the screen side.
That is what makes this decay expensive rather than merely untidy. The floor's proposed fix was to delete the whole conveyor, on the reasonable belief that only three of its zones were in use. The conveyor was driven every scan by live logic. One zone was orphaned. The other five references were wired into working color expressions.
Knowledge Sealed Inside Someone Else's Code
Some knowledge never decayed out of the organization, because it was never in the organization to begin with.
An engineer asked, in plain language, how a conveyor reports its OEE state. The routine they were reading only calls the instruction that decides it. The state machine, the alarm precedence, and the thresholds sit inside three vendor add-on instructions, among 148 in a 112 MB export, in a layer most sites treat as a sealed box. The rule that separates blocked from faulted is a single alarm-code threshold. Downstream full raises a code above the line, so it leaves the state at Stopped rather than faulting the conveyor. That pairing is the site's operating definition of blocked, and nothing on any screen says so.
The vocabulary had thinned out too. Roughly half the operator-facing abbreviations on that line had no confirmed expansion for the site. Not wrong, unconfirmed, which is what a naming scheme looks like after enough turnover. The honest move there was to flag them and tell the reader to ask a site expert instead of inventing plausible expansions, and it still means a person finishes the last mile on wording.
The Decay Is Invisible Until It Is Expensive
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.
The bill comes due as a mismatch between what everyone believes a system does and what it does. A sortation lane had been decommissioned in the warehouse host weeks earlier and the belts were still energized. The host action had worked exactly as designed. It cleared a routing enable, which tells the sorter to stop sending product to the lane, and has no relationship to the conveyor motors. Routing enable and motor enable are different systems that sound like the same sentence in a meeting, and nobody in that meeting was wrong on purpose.
The same session turned up a second piece of decayed knowledge with a longer fuse. Walking over and pressing stop would have appeared to work and would not have held, because the zone enable is latched by the area-wide start pushbutton. The lane would have come back on the next start of the shift, and nobody would have connected the two events. That is the kind of fact that gets rediscovered every few years by a different person, at the cost of a confused morning each time.
Decay also shows up as procedure that has degraded into folklore. After the five hour palletizer stop, one of the recommendations was simply to put pallet counts on the restart checklist. The controller assumes every pallet is full on first scan, which is conservative and correct, and the designed reset is a physical pallet exchange. That was known to some people some of the time. It was not written anywhere that a person recovering from an outage would read.
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.
The requirement is not storage. It is currency. A knowledge store that does not update is 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 plant as it was.
Two properties look load-bearing so far, and both came out of field work rather than design sessions.
A knowledge system has to know the difference between a thing that is quiet and a thing that is dead. That distinction is the whole ghost-reference problem, and it is also the rule behind a jam monitoring board that has run continuously at a sortation site: a stale collector renders as its own operator-facing state and never as "no jams", and interval ends that could not be established are flagged rather than filled in. Five out of 3,522 in the first two weeks. A memory that quietly interpolates over its own gaps is how decay gets laundered into confidence.
And it has to produce things people keep. The OEE session ended with a one-page operator reference: three reachable states, the alarm number and signal behind each fault, and a four-step triage list. At the sortation site the durable change was organizational. The site created a standing role working the repeat-offender table, which is a better sign that knowledge landed than any usage metric we could have collected.
Why This Is a Research Direction, Not a Product Feature
It would be easy to treat this as a documentation tool. 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. Atlas, a living model of how an operation works, is the system in development against that question, and it is a research direction rather than something shipping today. The comprehension work under it runs now, in Nexus, and it is where these examples came from.
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.