Choose authoritative sources
Start with the documents people already trust to make the decision: approved policies, current service information, maintained product records and explicit playbooks.
A folder full of files is not automatically a knowledge base. Each source needs an owner, intended audience, scope and review point.
- Named owner
- Approved purpose
- Current version
- Clear audience and scope
Write for retrieval and review
Separate distinct policies, use descriptive headings and state exceptions beside the rule they change. Avoid burying the effective answer inside long introductions or duplicate documents.
Structured scenarios help when a trigger, action, confirmation or escalation must be consistent.
- One topic per section
- Plain wording
- Explicit exceptions
- Visible confirmation and escalation rules
Test questions and evidence
A useful test asks representative questions and inspects both the answer and the exact source passage used. It also includes questions the source should not answer.
Coverage is not the same as correctness. Human reviewers still need to decide whether the source and resulting behavior match policy.
- Common question
- Ambiguous question
- Out-of-scope question
- Conflicting-source check
Maintain the operating loop
Knowledge changes when products, policies and workflows change. Give every important source a review owner and a way to report gaps from real conversations.
Quality findings should lead back to the source or workflow that caused the problem, not only to a score on an individual conversation.
- Review cadence
- Gap reporting
- Version history
- Re-test after meaningful changes
The best knowledge source is not the longest one. It is the source whose authority, scope and evidence are easy to understand.