The Living Knowledge System

The system beneath the documentation

8–11 minutes

The Doc Landscape is built on a premise: documentation is part of a living knowledge system. Not a deliverable or a phase of development, but one layer of something larger.

So, if documentation is part of a knowledge system, what does that system actually look like? Who else is in it? Where does documentation fit and where does it fall short?

This series exists to explore these questions seriously.

What Is The Living Knowledge Systems Series?

The Living Knowledge System examines how product knowledge is created, flows, degrades, and gets used across the full lifecycle of a software product, from discovery through operation.

It looks at documentation not as a standalone discipline but as one layer within a larger knowledge architecture. Some of that architecture is intentional. Much of it isn’t. And the gap between the two is where knowledge debt accumulates, where useful context disappears, and where documentation ends up playing catch-up with a system that was never fully designed.

The series maps that system: its stages, its tiers, its audiences, and its structural failure points. It also examines where documentation engineering fits within it and where the field is still working out what its scope should be.

The Mental Model for The Living Knowledge System

The following diagram is the foundation of the series. It maps the knowledge system across five product lifecycle stages, three knowledge tiers, five audience types, and the upstream and downstream flows that connect them.

It also shows where most companies under-invest: the pipeline that should move ephemeral knowledge into durable form before it disappears, and the retirement process that almost never exists for content that has quietly stopped being true.

Each section of the series expands on what the diagram maps.

The Doc Landscape · Mental Model Series

Knowledge Systems in
Software Companies

How product knowledge is created, flows, degrades, and where documentation engineering lives within it.

v1.0 · 2026
thedoclandscape.com
Foundational Reference
🔭
Discovery
Why build this?
What problem exists?
✏️
Design
What are we building?
What tradeoffs exist?
DDLC begins here
⚙️
Build
How does it work?
DDLC in full flow
🚀
Deliver
How do users receive
and adopt it?
🔄
Operate
What breaks, changes,
gets deprecated?
Ephemeral

Ad-hoc & In-the-moment

Exists in real time. Generated constantly. Vanishes without deliberate capture. Contains some of the richest context in the system.

  • Slack threads & DMs
  • Meeting decisions
  • PR review comments
  • Verbal SME clarifications
  • Design rationale in Figma comments
⚠ Under-invested: no pipeline to capture what matters
Versioned

Release-specific & Public-facing

Tied to a product version or release cycle. Tooling-heavy. Most visible. Where DDLC pipelines and CMS investment is concentrated.

  • API reference docs
  • Release notes & changelogs
  • User guides per version
  • Feature announcements
  • Migration guides
✓ Well-invested: DDLC, CMS, review workflows
Evergreen

Foundational & Long-lived

Intended to remain valid over time. Often created with care at the start — then neglected. Drifts silently until it misleads rather than guides.

  • Architecture overviews
  • Core concept glossaries
  • Onboarding guides
  • Platform principles
  • Style & terminology guides
⚠ Gap: created but rarely audited or retired
↑ upstream

Before the Build

The reasoning and decisions that explain why something exists and what it’s supposed to do. Most valuable. Most lost. Often reconstructed late through SME interviews — if at all.

Product requirements Research synthesis Architecture Decision Records Design rationale Tradeoff notes Technical specs
↓ downstream

After the Ship

Knowledge generated by the product living in the real world. Rich signal about where documentation failed or where the product diverged from its spec. Rarely fed back systematically.

Support ticket patterns CS call themes Bug reports User confusion signals Deprecation notices Behavior drift notes
🛠
Engineers
Architecture, APIs, implementation specs, ADRs
🧪
QA & Testing
Expected behavior, edge cases, test scenarios
🎧
Support & CS
Feature behavior, known issues, escalation paths
👤
End Users
How to use the product, task-oriented guides, onboarding courses, learning pathways
Movement gap 01
Ephemeral → Durable
No systematic process to identify which ephemeral knowledge is worth promoting. It decays before anyone decides.
The real gap
Lifecycle Ownership
Knowledge debt accumulates because no one owns the movement and retirement stages — only the creation stage.
Movement gap 02
Stale → Retired
Outdated evergreen content sits alongside current content with no signal it has drifted. Misleads rather than guides.
Where DDLC fits
The Production
& Distribution
Infrastructure
The documentation operations infrastructure is to the DDLC what the CI/CD toolchain is to the SDLC — the machinery that automates the lifecycle.
What DDLC does well
Manages the versioned tier. Brings engineering rigor to content production. Tracks ownership in git. Enables review workflows. Involves technical writers, content designers, and UX writers across Design through Operate.
What DDLC doesn’t address
Upstream knowledge capture. Downstream feedback loops. Retirement governance. Cross-audience knowledge architecture. Content modeling — which should precede DDLC implementation but rarely does.
Analogy
CI/CD doesn’t define engineering culture or product strategy. DDLC, or the operations infrastructure that it works in, doesn’t define knowledge culture. It operates within a larger system.
The missing piece
A company’s theory of knowledge — how it’s created, validated, maintained, retired, and surfaced. Most companies have practice but no theory.
01
No Ephemeral Pipeline
Valuable context — design rationale, decision history, technical tradeoffs — lives in Slack and meetings, then disappears. No one owns the process of deciding what gets captured and promoted to durable form.
→ Compounding loss over time
02
No Retirement Process
Evergreen content drifts silently. Users and internal teams have no signal to distinguish current from outdated. Trust in the knowledge system erodes gradually, then all at once.
→ Silent accuracy decay
03
Siloed Audience Views
The same product knowledge is duplicated and maintained separately across support, engineering, and end-user docs. Divergence is inevitable. A shared knowledge model with derived views is rarely designed.
→ Duplication & drift
04
Upstream Enters Late
Documentation teams often enter at Build — after discovery and design decisions are finalized. DDLC should begin at Design, but organizational structure frequently prevents it. Context must be reconstructed through interviews. Much is already lost or compressed beyond usefulness.
→ Thin, decontextualized docs
05
Downstream Doesn’t Loop Back
Support tickets and user confusion signals contain rich evidence of documentation failure and product behavior drift — but rarely flow back into content updates in any systematic way.
→ Broken feedback loop
06
No Theory of Knowledge
Most companies have knowledge practices but no knowledge theory. Tooling accumulates without architecture. Knowledge debt compounds like technical debt — until the system becomes unwieldy.
→ Tooling without strategy
Documentation engineering is the discipline that sits across the boundary between two layers: documentation-system design and documentation operations.
It shapes the architecture, then makes sure the operations infrastructure embodies those decisions.

Scope

Spans all five lifecycle stages, from Design through Operate — not just Build and Deliver. Includes upstream capture, downstream feedback integration, and retirement governance.

Role

Knowledge architect, not content producer. Designs the model, the flows, the governance — then selects the tools and pipelines that serve that model.

Strategic value

The company’s knowledge system is infrastructure. Documentation engineering is the discipline that intentionally designs and maintains that infrastructure.

Who Is The Living Knowledge System Series Is For?

This series is for you if documentation plays a meaningful role in how your organization builds or operates software and you’ve started to suspect that the problem you’re solving is larger than any single document, tool, or workflow.

More specifically, it’s for you if:

  • You document software products and have felt the gap between writing documentation and keeping knowledge usable as systems evolve
  • You work on documentation structure, reuse, and lifecycle and want a clearer model of the larger system you’re operating within
  • You’re a documentation engineer, or a technical writer moving in that direction, and want to understand how the field’s scope is expanding beyond content production
  • You work in a role that depends on product knowledge (engineering, QA, support, or content design) and want to understand why knowledge systems break down even when individual contributors are doing their jobs well

You don’t need a background in knowledge management. You do need to care about whether knowledge stays usable over time.

How Is The Living Knowledge System Organized?

The series is organized into five sections, each corresponding to a layer of the mental model diagram above.

  • The System introduces the full model in detail: what each layer means, how the pieces connect, and why companies with mature documentation pipelines can still have broken knowledge systems
  • The Knowledge Tiers articles discuss ephemeral, versioned, and evergreen knowledge types — how each tier behaves, where investment goes, and where it doesn’t
  • The Knowledge Flows articles examine upstream and downstream knowledge movement. Why documentation enters too late to capture the context that matters most, and why downstream signals rarely find their way back into content
  • The Knowledge Audiences articles discuss each audience the knowledge system serves (product, Design/UX, engineers, QA, customer support, customer success, end users, content owners) what each needs, and where the system typically fails them
  • The Knowledge Infrastructure articles cover the DDLC, the architectural layer that designs the knowledge system, the operations infrastructure that implements it, and documentation engineering as the discipline spanning both.

Articles can be read in sequence or by section. The mental model diagram is the fastest way to orient before diving in.

What This Series Does Not Cover

This series does not cover:

  • Knowledge management as an enterprise discipline or organizational practice
  • Specific tooling recommendations or platform comparisons

Where to Start

If you’re new to this series, start with The Knowledge System in Software Companies — the written companion to the mental model diagram. It covers the full system in prose and sets up everything that follows.

If you already have a specific question in mind, go directly to the relevant section:

How This Series Relates to the Rest of The Doc Landscape

The Living Knowledge System is the foundational series on this platform. It maps the system that documentation operates within — the full lifecycle of product knowledge, from the moment it’s created to the moment it’s retired or lost.

The other series on this platform focus on different layers of that system. Writing craft and foundational documentation principles live in Technical Writing Best Practices. Documenting AI products and features specifically lives in Writing About AI. Writing and structuring documentation so AI search and retrieval systems can surface it reliably lives in Writing for Retrieval. Exploratory thinking, observations, and reflection on how documentation work is changing live in Reflections.