Your website, an old proposal and a shared document may describe three different versions of the same service. Giving AI more context will not resolve that conflict by itself. First decide which source is authoritative for each fact and who keeps it current.
Separate business facts from useful background
Build a register for facts that change a customer’s decision: service scope, price conditions, prerequisites, delivery commitments and the next step. A historical presentation may explain the business well while containing an expired offer. Mark it as background rather than letting it compete with current terms.
Use publicly approved information for public answers. Keep internal estimates, drafts and private customer material outside the source set unless a specific authorised task needs them. More documents are not automatically better evidence.

Start with this register
| Fact | Record to maintain |
|---|---|
| Service scope | Approved live page and responsible owner. |
| Price conditions | Current source, currency and applicable limits. |
| Requirements | Supported software and access prerequisites. |
| Delivery | Published commitment or needs confirmation. |
| Exceptions | What an answer must send for human review. |
Add last checked date, change owner and replacement source. A date alone does not prove that someone checked the facts. Record the specific change or confirmation that occurred.

Original illustrative guide: Set It Once. A link to an old document does not make an outdated fact current.
Read the text version
- Record the fact. Price, scope, prerequisite or availability.
- Link the authority. Use the approved current source.
- Name an owner and review date. Define who keeps it up to date.
- Resolve conflicts explicitly. Do not let AI guess between versions.
Make disagreement visible
Hypothetical example: an old PDF says setup takes one day, but the current service page says timing is agreed after access checks. The correct action is to use the approved current source and avoid turning the old estimate into a promise. If the register itself is unclear, return the question to the owner rather than choose the more attractive answer.
Ask the AI to distinguish an explicit fact, an inference and missing information. Request the source URL for a factual answer, then open that source yourself. A plausible citation can still point to a page that does not support the statement.
Run a stale-answer check after changes
- Choose five common customer questions and record the approved answers.
- Change one fact in a controlled source set.
- Refresh the connected source using its documented process.
- Ask the same questions and compare the new answers with the register.
- Check what happens when the relevant fact is absent.
The desired result for missing information is an honest boundary and a useful next step, not a fabricated completion. This register and test are planning tools; they do not claim that every connector automatically refreshes sources or grounds every answer. Confirm those behaviours in your actual setup.
Make one register entry precise enough to resolve a conflict
For a hypothetical setup service, a useful entry could read: fact “delivery timing”; authority “approved live service page, timing agreed after access checks”; owner “service lead”; historical PDF “background only”; unknown case “do not promise a date; request confirmation”. This is more actionable than putting several URLs in a folder and calling it a knowledge base.
Split compound claims. “Setup costs X and is delivered tomorrow” contains price, scope and timing, which may have different authorities and conditions. Keep the relevant qualifications with each fact, including currency, included work and prerequisites. An answer that copies the headline price but omits its scope can still mislead.
Define authority before recency
The newest document is not automatically the approved one. A draft proposal created today may have less authority than a current service page approved last week. A private estimate may be accurate for one customer but inappropriate for a public answer. Use approval status and intended audience alongside dates.
When sources conflict, identify the disputed fact, both source versions and the person who can decide. Do not let the assistant average prices or choose the more attractive commitment. Until resolved, its answer should state the confirmed boundary and a useful way to obtain the missing detail.
Test whether a changed fact reaches the answer
In an isolated source set, change one approved condition and record the source version. Follow the actual connector’s refresh process, then ask the same question in a fresh interaction and one with older context. Check the answer and its supporting source. This can reveal stale retrieval or retained conversational assumptions.
Record source update, refresh completion, test question, answer and supporting passage. If the answer remains stale, investigate which source was used before rewriting prompts repeatedly. Remove or clearly separate obsolete material where the system supports it. A source register controls editorial authority; it does not guarantee that a particular AI product retrieves, refreshes or follows it correctly. Those behaviours need their own observed tests.
Take one practical next step
If you want AI to work with your WordPress website, review the prerequisites for Connect Website to AI. Scope, timing and price are agreed before work starts. An enquiry does not place an order or guarantee a result.
Sources and further reading
Quick answers
Frequently asked questions
Should the newest document always win?
No. Authority and approval matter as well as date. A new draft may be less authoritative than an approved live page.
Can a public page be the authoritative source?
Yes, when its owner has approved the information and maintains it. Record which facts it governs.
What if two approved sources disagree?
Pause the affected answer and ask the responsible owner to resolve the conflict. Do not silently invent a compromise.




