Corthex · Evidence / freshness
A source tells you where. Fresh data tells you when.
A cited answer can still be outdated. Choose evidence according to the fact you are trying to establish, not the presence of a source link.
Traceability and freshness answer different questions.
A source reference helps you inspect where an answer came from. It can show the policy page, document or passage that supports the explanation. That is useful evidence of origin, but it does not establish that the source was updated after a price change, that a product is in stock now or that a visitor is authorized to see a private order. Those questions require additional evidence with a different scope.
For a webshop assistant, separate stable business knowledge from changing store facts and private customer context. An approved returns page can explain a procedure. A current product result can provide a price field when the connector supports it. A private order lookup needs both a permitted tool and verified customer identity. Combining these in a conversation is useful; treating them as interchangeable is not.
Change one value, keep the reference
The citation survives the price change. The price does not.
Controlled local example · Fictional product, no store requests
A citation can still point to this value after the store changes. The reference identifies the source, not a live price guarantee.
Available from the simulated store at question time. A real integration must return the relevant field before you can make the same statement.
The fictional current store result is €45. The cited source records €45. Explain the difference instead of treating the citation as proof that the source is current.
Give each data class its own evidence rule.
| Question | Useful source | What it establishes | What it does not establish |
|---|---|---|---|
| How do returns work? | Reviewed policy and instructions | The documented process and its explicit conditions. | Approval of this customer’s return or an executed refund. |
| What is this product’s price? | Current relevant store result | The returned price field at that lookup, for the specified product/context. | Every future price, an unreturned option price or completed checkout total. |
| Is this combination available? | Product/variant constraints and available live fields | The specific supported options and availability actually returned. | A combination assembled from unrelated source pages. |
| Where is my order? | Authorized own-order tool result | The verified customer’s permitted order fields. | Another customer’s order, a guest’s identity or an unreturned carrier ETA. |
A live tool still has boundaries.
A connection being available does not mean every fact is returned. Check the tool’s actual fields, resource scope and selected product or customer. Some integrations are read-only. A current read does not imply permission to change a cart or order. If a field is absent, state the limit and offer an appropriate route rather than inventing the missing value from general knowledge.
A generic embed is a display route, not a store credential. Native WooCommerce requires explicit pairing and verified signed-in own-order context. The PrestaShop module uses its scoped read-only Webservice. A custom site action requires real host support and authorization. Keep these distinctions visible when a conversation moves from policy explanation to a specific customer request.
Source refresh needs an owner.
Decide who updates a source when your policies or catalog explanations change. Record whether you imported a snapshot, refreshed website content or requested a live tool. A date on the original website does not by itself prove that an older imported copy has changed. Retire superseded versions and repeat the questions whose expected answers depend on the changed fact.
When sources disagree, identify the conflict explicitly. Asking a prompt to always choose the newest-looking sentence is weaker than keeping authoritative content consistent. Assign the correction to the source owner and preserve a test that reproduces the conflict. The aim is an answer whose conditions you can explain, not a decorative citation attached to an uncertain claim.
A useful answer separates what is known from what was checked.
For example, a source may explain standard delivery steps while the order tool returns only Processing. The assistant can explain both, but should not combine them into a promise that this parcel arrives tomorrow. State the actual order result, explain the relevant policy and identify the missing delivery fact. If the connector fails, say the personal lookup could not be completed and give the store’s support route.
Do not publish a real customer’s private order as evidence for this distinction. Fictional orders and a controlled product change are enough to test the logic. The example above is deliberately local and simulated; it demonstrates why the distinction matters, not that a particular live installation or refresh schedule has passed.
Your own controlled test
Repeat the same question under changed conditions.
- Create a fictional test product and one reviewed source. Record the initial value in both and the expected answer.
- Change the product value in your own staging store while leaving the source snapshot unchanged. Inspect which result the assistant actually uses.
- Refresh the intended source deliberately and record what changed. Do not assume every imported copy updates automatically.
- Make the connector unavailable in the controlled test and check that the assistant acknowledges the missing live evidence. Save the result in your acceptance review.
Refreshing a source and retrieving live data solve different problems. Manage the website source snapshot; then review the budget for the context you actually send.