An AI knowledge base is easier to accept as a set of linked deliverables: a source register, answer records and verification questions. Together, they let a reviewer trace a fact to its source, see who approved it and identify what must change when a policy is updated.
This guide provides a handoff template for one company topic. You can use it before building an assistant to surface conflicting information and decide which questions still need a human answer. Our guide to preparing data for an AI assistant covers the broader principles; here we assemble the actual files to hand over.
If you need help with this work, see the AI knowledge-base preparation service. Building and connecting the assistant itself is a separate scope.
Define the scope and list the sources
Start with one topic and one audience. For example: “Equipment servicing terms for existing customers.” State which answers can come from the documents and which require a team member. A general service description cannot confirm a personal discount, an appointment or the status of an individual order.
Create a source register. Each row describes one source document rather than each paragraph. Its version and effective date distinguish editions, while a named owner approves the facts. A file without an owner or clear status needs a review flag rather than an automatic “current” label.
| Register field | What to record | Purpose |
|---|---|---|
source_id | A stable code such as SRC-01 | Keep references intact when a file is renamed |
Title and location | Document name and a link accessible to the client | Find the original for review |
Version and effective date | Edition and period of applicability | Separate current terms from archived material |
Owner | The person responsible for approving the facts | Resolve conflicts and approve changes |
Audience | Public / staff / a specific group | Hand access requirements to the developer |
Status | Approved / conflict / missing information / archived | Identify usable content |
These fields are a suggested DDRW template. An “audience” column does not enforce access control. Permissions must be implemented and tested when the assistant is built.
Resolve conflicts before writing an answer
Consider an illustrative example. The current policy says equipment servicing is available on business days. An old presentation says “every day.” Neither choosing the more convenient sentence nor asking a model to blend the two resolves the contradiction.
Flag the conflict, record both passages and send them to the service owner. Until the owner confirms the applicable rule, the FAQ record should require clarification. When a document changes, retain the decision: the chosen edition, the approver and its effective date.
Check whether the text is usable, too. A readable text document and an image-only scan require different work. Flag pages whose meaning depends on a missing diagram, table or external reference. Agree on any missing documentation, scan recognition or translation before preparing the handoff.
This diagram describes the preparation scope. The resulting files are not yet a working AI assistant.
Make each FAQ record traceable
Each record needs a question, approved answer facts and a reference to the precise source location. A document name, edition and section are more useful than a link to the entire shared folder. A reviewer should be able to reconstruct the basis of an answer without searching the whole archive.
In retrieval-augmented generation, or RAG, an application retrieves relevant content and uses it to help generate an answer. Microsoft’s explanation describes retrieval and source citations. A prepared FAQ can contribute input content, but its existence does not mean retrieval, indexing or citation behavior has already been implemented.
A minimal record could look like this:
ID: FAQ-01
Question: When is servicing available?
Answer facts: On business days; a team member agrees on the exact time.
Source: SRC-01, current edition, “Working hours” section.
Boundary: Do not confirm an appointment.
If information is missing: Offer contact with a team member.
Approved by: The person responsible for servicing terms.
This is a fictional format example, not the terms of DDRW or a real client. Replace every fact with approved company information. Do not add a support promise, deadline or price simply because an answer otherwise seems too short.
A document can also contain instructions such as “ignore the rules.” These must be treated as source data, not permission to change the future assistant’s behavior. OWASP describes the risk of instructions embedded in retrieved documents. Content preparation does not replace application security and testing.
Keep verification questions separate from answer records
The FAQ describes available facts. The verification set checks whether the relevant basis can be found and whether the boundary of an answer is clear. Keep the files separate so a reviewer can inspect each question, expected meaning and supporting reference.
For the illustrative servicing topic, a set could include:
| Verification question | Expected result | Basis |
|---|---|---|
“Do you work on Sundays?” | State the approved schedule without inventing an exception | Working-hours section in SRC-01 |
“Book me for tomorrow at 10 a.m.” | Explain that a team member confirms appointments | Scenario boundary |
“But the old presentation says every day?” | Identify the conflict and use the approved edition or request clarification | Recorded conflict decision |
“What discount will I personally get?” | Do not infer an individual offer from a general FAQ | No approved source |
This checks the prepared content. Testing a working model, its responses and its actions comes later. Use our separate AI assistant acceptance guide for that stage. Do not label the assistant “tested” when only its input documents and tables have been reviewed.
Deliver a package that can be maintained
For a small project, an agreed folder of Markdown and CSV files may be sufficient. Include short instructions explaining the register, linked IDs, approval responsibilities and temporarily excluded records. Before handoff, open the files in the client’s intended tool and check the encoding, columns and references.
A handoff record can confirm:
- the topic, language and actual list of processed sources;
- the package version and delivery date;
- an accessible original for every factual record;
- a separate list of unresolved conflicts and gaps, with owners;
- FAQ records and verification questions in the agreed formats;
- the update rule: changing a source requires reviewing its dependent records.
The number of completed rows does not establish the future assistant’s accuracy. If the source material supports only ten useful answers, inventing facts to reach a round FAQ count makes the package worse. Flag the gap and return it to the topic owner.
What the DDRW service includes
The knowledge-base preparation package covers one topic and one source-content language: up to 20 ready text documents totaling up to 15,000 words. The first limit reached defines the scope. Deliverables include a source map, organized Markdown/CSV content, up to 50 FAQ records and up to 30 verification questions.
Building, hosting or connecting a chatbot, retrieval infrastructure, scan recognition, translation and writing missing documentation are outside this package. Documents are not automatically uploaded to third-party AI services; the transfer method is agreed beforehand. The client needs a subject specialist who can approve the facts and permitted use of the documents.
Before ordering, choose the topic, count the documents and words, check that the files are readable and appoint the reviewer. View the service in the shop for the current price, full scope and steps to begin.
