Which version of that answer is current?

Someone asks an internal assistant how to handle a customer request. The answer differs from the one a colleague received last week. Both sound reasonable. Both point to a procedure document. Which answer should guide the work?

We would start by asking what changed. The procedure may have been revised. The system may have found a different passage, received new instructions, or used a different model. The colleagues may also have different permissions. A change in wording alone does not tell us whether the guidance changed or whether either answer is suitable.

For a buyer evaluating AI inside a company, this is an operating question. Can the people responsible for the work investigate an answer before someone acts on it? We want that question addressed during a small evaluation, while the workflow and its limits are still open to revision.

Define what current means

We begin with a valuable question and the decision it supports. A hypothetical example is helping staff find the approved procedure for handling a returned item. We would define who asks, what information they need, and where the assistant's job ends. Drafting guidance does not have to include authorizing a return or changing a customer record.

Next, we identify approved sources and their owners. A document's recent upload date does not establish that its guidance is in effect. We need to distinguish when a procedure was approved, when it takes effect, and when the answering system last received it.

Freshness expectations should follow the work. If a procedure changes, must the system pause answers until the change is available? Can it display the last checked version while sending the question to a reviewer? We would agree on that behavior before testing, including what happens when a source owner cannot confirm its status.

Conflicting documents need a decision too. The system should not silently treat the most recently edited file as the authority. We ask which source takes precedence and who resolves an unresolved conflict.

Keep the trail behind an answer

An answer's timestamp only tells us when it was produced. A useful review record connects that answer to the inputs and configuration used at the time.

For the bounded workflow, we would preserve enough to identify:

• The question and relevant context supplied to the system.
• The source versions and passages actually used, with their effective dates where available.
• When those sources were checked or included in the retrieval index.
• The model identifier, available version information, settings, prompt, and instructions.
• The application and retrieval configuration, including filters that shaped the search.
• The permission context, review status, and any later correction.

A retrieval index is the searchable representation the system uses to find source material. Updating the original document does not by itself establish that this representation has refreshed. We would test that path rather than assume the next answer will reflect the edit.

The record also needs limits. We would define access and retention for questions, passages, and outputs. Where retaining a source copy is appropriate and authorized, it can support later comparison. Where it is not, we need an approved reference and an explicit account of what cannot be reconstructed. Copying restricted material into a broadly visible log would create a separate problem.

Compare the change, not just the prose

We would compare the older and newer answers alongside their source and configuration records. Did the governing procedure change? Did retrieval select an obsolete passage? Did a prompt revision remove an instruction to ask for review? Did a permission change make an expected source unavailable?

These diagnoses call for different responses. Rewriting a prompt will not settle a disputed company policy. Refreshing an index will not grant a user permission to read a restricted document. A reviewer needs enough context to send the issue to the person who can resolve it.

Even a detailed record does not promise exact reproduction. Generated wording can vary, and a provider may not expose every change behind a model identifier. We would record those limits. The practical aim is to explain what is known about the difference and decide what evidence or review is still needed.

We also distinguish a historical answer from current guidance. An answer accepted under an earlier procedure may be useful evidence of what happened then. It should not become today's approved instruction merely because someone saved it.

Test ordinary cases and awkward ones

We scope the evaluation around the selected question before connecting a large document collection. We assess source quality, permissions, data handling, and the existing process. A clearer procedure or conventional search may be sufficient.

For an AI test, we define what an acceptable answer must include and when it must defer. Representative cases should cover ordinary requests as well as missing guidance, conflicting versions, future effective dates, stale retrieval, and restricted sources. We would also test what happens when a document is withdrawn or a user's access changes.

Reviewers compare the output with the approved guidance. A citation is something to inspect, not proof that the answer follows the cited passage. We check whether the response applies to the question, respects the user's access, and makes unresolved issues visible.

When we change a source or configuration, we rerun relevant cases and compare the records. Keeping revisions small helps reviewers connect a changed result with a plausible cause. We expand only where the evidence supports the next step.

Give uncertainty an owner

An uncertain answer needs a destination. We would name the procedure owner who settles policy questions, the reviewer who approves guidance, and the technical owner who investigates retrieval or configuration failures. We would also define how staff continue when those people are unavailable.

The handoff should let an authorized operator find an answer's record and follow that route. Support boundaries belong beside it: who maintains source updates, who approves configuration changes, and which failures require the workflow to pause. Those responsibilities need agreement; they should not be inferred from access to the software.

As an AI-native strategy and engineering studio, we treat this as part of evaluating whether AI belongs in the process. The useful result of a small test is evidence you can inspect, including reasons to revise or stop. Before expanding, we want your reviewer to be able to identify the answer's inputs, judge their currency, compare the relevant versions, and put an unresolved question in the right hands.