| name | knowledge-base-design |
| description | Design an internal or customer knowledge base around audiences, recurring questions, source authority, article types, navigation, search, ownership, permissions, freshness, and feedback loops. |
Knowledge Base Design
Use when organizational knowledge needs a durable retrieval system rather than scattered documents and chat history.
Procedure
- Define the audiences, recurring decisions or questions, confidentiality boundaries, and systems that already contain authoritative knowledge.
- Choose knowledge article types such as procedure, policy, troubleshooting, FAQ, reference, decision, glossary, or incident learning according to actual retrieval needs.
- Organize around user-recognizable domains and tasks rather than organizational silos unless ownership itself is the retrieval key.
- Define metadata, tags, search terms, cross-links, audience or permission scope, and source references that support discovery and trust.
- Assign one accountable owner and review signal to knowledge whose accuracy decays.
- Prevent duplication by linking to authoritative source systems instead of copying volatile data into several articles.
- Define contribution, review, correction, archival, and feedback workflows that are lightweight enough to use.
- Test findability with realistic questions and revise taxonomy or content when users cannot locate an existing answer.
Decision rules
- A knowledge base should help people find trusted answers, not store every document the organization owns.
- Link to authoritative volatile data instead of duplicating it.
- Permissions and audience scope are part of knowledge architecture.
- Ownership and freshness matter as much as initial writing quality.
Quality gate
The design is ready when common questions map to discoverable trusted content, authority and ownership are visible, permissions are appropriate, duplication is controlled, stale knowledge has a lifecycle, and retrieval tests show users can find the intended answer.
