What does it mean that documentation as schema preservation?

Documentation is not just a record of what exists. It is a preservation mechanism for organizational schemas — the shared mental models that explain why things are the way they are, not just what they are. Documentation that captures schemas (the reasoning, the context, the tradeoffs) preserves the organization's cognitive capacity. Documentation that captures only facts (the current state, the procedure, the configuration) preserves information but not understanding.

Example: Two engineering teams at the same company maintained internal wikis of similar size — approximately 500 pages each. But the quality of knowledge preserved was dramatically different. Team A's wiki consisted primarily of factual documentation: API references, configuration settings, deployment steps. Each page described what something was and how to use it. Team B's wiki included factual documentation but also captured schemas: Architecture Decision Records explaining why the system was designed a certain way, incident retrospectives explaining how failures were diagnosed and what was learned, and design proposals documenting the alternatives that were considered and rejected. When both teams experienced 40% turnover in the same year, the impact was markedly different. Team A's new members could operate the system — the factual documentation told them what to do — but could not make design decisions, because they did not understand why the system was built the way it was. Every architectural question required finding one of the remaining original members and asking for context. Team B's new members could both operate and evolve the system — the schema documentation gave them the reasoning behind the current design, which enabled them to make decisions consistent with the established architectural direction without asking for permission or context. Team B's documentation had preserved not just information but organizational intelligence.

Try this: Choose one important system, process, or decision that your team is responsible for. Check the existing documentation. Does it capture only what (current state, procedures, configurations) or does it also capture why (design rationale, alternatives considered, tradeoffs accepted)? If the documentation is facts-only, write a one-page schema supplement: 'This system was designed to solve [problem]. The key design decisions were [1, 2, 3]. For each decision, the alternatives considered were [X, Y] and the reason this option was chosen was [reasoning]. The most important tradeoff this design accepts is [tradeoff].' This one page preserves more organizational intelligence than ten pages of factual documentation.