Some systems appear considerably more complete than they really are.
Everything works. Deployments happen. Customers get answers. Problems are resolved. Someone knows which configuration value matters, which procedure has an undocumented extra step and why the strange-looking piece of code nobody likes can't quite be removed yet.
Then that person goes on vacation.
Nothing necessarily crashes. Instead, ordinary questions become unexpectedly difficult. Why was this value chosen? Which version was actually approved? Is that workaround still necessary? Did we decide to replace this service, or did we merely discuss replacing it? Someone eventually reconstructs the answer from an old email thread, a commit message, a Slack conversation and the memory of another person who was in the room three years ago.
The system had state. We just hadn't noticed where some of it was stored.
Small organizations can operate this way for a surprisingly long time because people are extraordinarily good at filling gaps. Decisions happen in conversation, context travels through relationships and someone who has seen the same problem before recognizes it immediately. Formalizing all of that would take time, and when the same few people remain involved every day, the return may not seem worth the effort.
Sometimes it isn't.
Not every conversation needs minutes. Not every judgment needs to become a rule. If two people are working together for an afternoon, stopping every ten minutes to preserve their shared context for a hypothetical future employee would probably make the work worse rather than better.
Implicit knowledge isn't automatically technical debt.
The question changes when continuity begins to depend on it.
I've encountered old software that contained behavior nobody could explain until someone remembered a customer requirement from fifteen years earlier. I've seen processes with steps that looked unnecessary until we recovered the failure those steps were preventing. I've also seen procedures everyone followed because somebody once said they were necessary, long after the original reason had disappeared.
Those situations look similar from the outside. Something exists, the explanation is missing, and changing it feels dangerous.
That's when memory becomes an architectural concern.
Human memory is remarkably useful for carrying context, but it doesn't preserve information the way a database does. We compress experience. Details disappear. Later events change how earlier ones are remembered. Several conversations become one general impression of what “we decided,” and sometimes two people leave the same meeting carrying different versions of the decision.
That isn't a defect in people. Exact archival storage isn't what human memory is for.
Problems begin when a process quietly requires it anyway.
The obvious response is documentation, although documentation alone doesn't solve much if nobody knows whether it still describes the system. A beautifully written procedure from four years ago can be more dangerous than no procedure at all if everyone assumes it remains authoritative after the implementation has changed.
So the useful question isn't simply whether information has been written down. It's whether the information needed to operate, change and recover the system has somewhere durable to live and some way to remain connected to what actually happens.
Sometimes the software itself is the best place.
A deployment step that must always occur can become part of the deployment process. A configuration value can live in version control instead of someone's notes. A schema migration can record a transition that would otherwise have to be remembered. Tests can preserve the knowledge that a particular behavior matters without requiring the next engineer to know which production failure originally taught us that lesson.
Other knowledge belongs somewhere else. An architectural decision may need a short explanation of the alternativ