The newest upload is not necessarily the current procedure

A timestamp tells you one event, not authority

A file uploaded yesterday may be a scan of a five-year-old procedure. A document modified today may be a draft awaiting approval. A current policy can have an old filesystem timestamp because it has not needed revision. Do not use file dates alone to decide which source should govern an employee answer.

Ask the owner to identify the approved version, effective condition and audience. For an instruction with a transition period, record when the new rule begins and what applies before it. If nobody can establish this, preserve the uncertainty instead of allowing the assistant to select the most recent-looking copy.

Write a version decision before ingestion

Use a small decision record: source identifier, approved version, effective date or condition, owner, retired versions and permitted purpose. Include local copies that remain in use. A technical ingestion success is not an authority decision.

For a fictional purchasing pilot, v2 names Priya and Friday, while v1 names Lee and Monday. The owner approves v2. A supported answer must not merge the two into a third procedure or treat the old copy as an equally valid alternative.

Test three questions, not just the new wording

1. Ask an ordinary question supported by v2. Record the answer and supporting passage.
2. Ask a question framed around the retired rule. Check whether the answer corrects the premise rather than repeating it.
3. Ask during a transition or with missing applicability. Expect a clarification when the audience or effective date changes the answer.

Keep the source reference and accepting reviewer beside each result. Do not accept a new version simply because one question produced its wording.

The retired-rule question is especially revealing. A demonstration can look successful because the new rule was quoted once, while the old wording still produces the old answer. Use both phrasings. A correct response should establish applicability, not merely repeat the visitor's premise.

Distinguish source publication from deployed freshness

A policy owner can publish a new document before an answer experience has retrieved or indexed it. Ask the implementer to show the refresh path and failure behavior. The public website's fetch policy does not prove how a separate internal knowledge store refreshes.

After a controlled update, repeat the known questions. Inspect which version is cited. If the source cannot be retrieved, decide whether the system should hold, show its limitation or direct the employee to an owner. Do not accept a fallback guess as evidence of resilience.

Retire the answer path, not necessary audit records

An old version may have a legitimate retention purpose. That does not mean it should remain eligible as current guidance for every employee. Separate historical retention from the permitted answer-source set. Preserve records according to the company's requirements while removing ambiguity from the current workflow.

Ask where copied extracts live: onboarding packs, saved snippets, learning material and local checklists. A canonical source change can leave those downstream copies stale. Give affected owners a repair and retest task rather than assuming the central edit reached everything.

Make the review decision observable

Record the change, affected audience, retested questions, result and accepting reviewer. Count stale-answer failures and time to accepted repair. Include recurring maintenance effort when deciding whether the first pilot is sustainable.

Use the source-change use case to structure the test. Request a demo with one current and one retired synthetic procedure. A convincing answer matters less than proving which rule it used and what happens when that rule changes.