Choose Reliable Sources for an AI Assistant
Rank candidate documents by authority, currentness, clarity, and duplication, then have the policy owner resolve conflicts before customers rely on an answer.
Choose sources by evidence, not convenience
An assistant can only give dependable answers when its source material gives the business a dependable answer to begin with. A folder full of documents is not automatically a knowledge base. It may contain an old promotion, a draft policy, a regional exception, and a current customer guide that all describe the same subject differently. Before adding material, decide which source is authoritative, who owns that decision, and what a reviewer should do when two plausible sources conflict.
Start with a real question the assistant is expected to answer. For a returns assistant, that might be, “Can I return an opened item?” Identify the exact policy passage that answers it, then trace that passage to its source and approval. A product brochure may be easier to find than the returns policy, but convenience does not make it authoritative. If the answer depends on purchase date, product category, or jurisdiction, make sure the selected material states those conditions rather than leaving the assistant to infer them.
A practical review compares four qualities. Authority asks whether the source is approved by the person responsible for the policy. Currentness asks whether it reflects the rule in force now. Clarity asks whether a reader can identify the rule and its exceptions without guessing. Duplication asks whether another file repeats or contradicts it. These checks belong to the team's editorial process. They are not a promise that software can decide which policy wins.
Build a source decision record
For each candidate, record its title, owner, approval date, effective date if applicable, intended audience, and the questions it supports. Add a short reason for keeping or excluding it. This record can live in the team's existing governance document; it need not become a new product workflow. The goal is to make later maintenance explainable. When a reviewer sees two documents with similar wording, they can trace the decision instead of choosing the newest-looking filename.
Consider a small retailer with a public return page and an internal draft proposing a longer holiday window. The draft is not evidence of an approved change. The policy owner should confirm whether the extension was adopted, when it applies, and whether it covers all products. Until that decision is documented in the canonical source, exclude the draft from material used to answer customer questions. If the owner cannot resolve the conflict, the assistant's safe behavior is to avoid asserting either version.
Prefer focused, readable material over an indiscriminate archive. Resonoon's knowledge editor supports PDF and Markdown uploads, with an effective per-file limit of 50 MiB. This does not mean every file within that size is useful, or that every format is accepted. Split a long handbook only when the resulting sections remain accurate and understandable on their own. Keep headings, definitions, dates, and exception language together so a passage does not become misleading when read outside its original context.
Check for ambiguity and hidden conflicts
Review a source as if you were a customer who has not seen the surrounding discussion. Does “within 30 days” specify what event starts the period? Does “eligible items” point to an actual list? Are taxes, delivery, or regional rules addressed where relevant? If two sections use different terms for the same product or customer group, resolve the language with the owner. Do not rely on the assistant to reconcile inconsistent policies or silently select the sentence that sounds most confident.
A useful test set includes a straightforward question, a boundary case, and a conflict case. For the return example, ask about an unopened standard item, an opened item, and an item bought during the proposed holiday window. Write the expected answer and the source passage beside each prompt. If the source cannot support a stable expected answer, that is a content decision to resolve before launch, not a prompt-writing problem. Repeat the test after the canonical policy changes.
Look at the assistant's answer for both correctness and restraint. It should include relevant conditions, avoid extending a rule to an unmentioned case, and say when the supplied material does not settle the question. Compare its wording to the approved passage. A plausible answer can still be wrong if it omits a qualifying date or turns an exception into a general rule. Keep the source excerpt and observed answer together so a reviewer can identify whether the gap comes from the document or the assistant's response.
Keep the decision current
Assign an owner and a review trigger to each consequential source. Triggers might include a policy revision, a price change, a new product line, or a recurring question that exposes missing context. A calendar reminder can help, but a named person and a clear event matter more than a vague instruction to “review regularly.” When the owner approves a change, replace or update the canonical material and retire obsolete copies from the knowledge set. Preserve internal records according to the business's own retention policy.
After the update, retest the questions that depend on the changed passage and a few neighboring questions that might be affected. Record the date, source version, prompts, and results in the team's review log. Do not promise that edits to a connected source appear immediately in answers. Check the visible source status and available last-synced details before treating the refresh as complete. For background on the customer-facing experience, see the AI chatbot widget.
The useful outcome is not the largest possible collection of files. It is a smaller, explainable set where each important answer has a responsible owner and a traceable basis. When source authority, currency, and wording remain uncertain, keep that uncertainty visible and route the decision to the person who can resolve it. This gives the assistant a defensible boundary and gives the team a repeatable way to improve its knowledge without asking a language model to invent policy.