An hour, a day and a week after a wrong answer

This is not a question of whether. Any system that answers from documents will eventually answer from a document that was wrong, or stale, or missing the condition that mattered, and it will do so in a confident sentence with your name on it.

What varies is the response. In organisations with no plan, the first incident produces a scramble: an argument about whether to turn it off, a defensive explanation of how the technology works delivered to somebody who does not care, a hurried instruction added to the configuration by whoever had access, and no reply at all to the person who reported it. All of that becomes precedent.

The alternative is a short written plan covering three timescales. What happens in the hour, what happens in the day, what happens in the week. It fits on half a page and it is the difference between an incident and a mess.

Reproduce it first, and capture what you find before you change anything. Ask the same question in the same words, save the transcript, and note which source the answer came from. This matters because the fix destroys the evidence: once you correct the page, you can no longer show anybody what happened or check whether your fix addressed the actual cause.

Where answers carry numbered citations, this step is short, because the passage that produced the claim is named rather than guessed at. Where they do not, you are searching your own material for the sentence that could have produced the sentence you are looking at, which is slower and sometimes inconclusive.

Then stop it repeating, by the crudest means available. Correct the offending passage if that can be done in minutes. If it cannot, remove the document from the indexed set, or narrow the scope, or raise the threshold so the question refuses instead of answering. All of these are reversible and none of them require a meeting. What does require a decision in advance is who is allowed to do them: somebody has to have the authority to pull material immediately, alone, without asking, and that person's name should already be written down.

This gets forgotten every time, because the incident becomes an internal event within about ten minutes and the reporter drops out of it. They should not. Somebody who tells you your system is wrong has done you a favour at their own expense, and an automated acknowledgement in reply is close to an insult.

The reply should come from a named human, quickly, and should contain four things: thanks, what was wrong, what is actually true, and what has been done about it. Nothing else. Do not explain how retrieval works. Do not describe the assistant as separate from the company, because it is not, and a customer reading that hears an organisation dodging. Do not promise a broader review you have not scheduled.

If the wrong answer cost them anything, deal with that first and separately, before the explanation. A person who has been reimbursed or rebooked will read your explanation calmly. A person who has not will read it as an excuse, whatever it says.

If the assistant quoted a price, a discount, a delivery date or a policy that is more generous than the truth, somebody now has to decide whether you stand behind it. This is a business decision with a deadline, not a legal seminar, and the deadline is roughly the length of the customer's patience.

For small amounts the answer is almost always to honour it. The cost of the item is bounded and known. The cost of arguing is staff time, a customer who will tell the story, and the awkwardness of a business explaining that its own website does not count. Very few disputes at that scale are worth winning.

Where the amount is large enough that you genuinely cannot, say so plainly and quickly rather than slowly and carefully. Explain what happened, state what the correct terms are, and offer whatever you can. What damages people is not the refusal, it is a week of vagueness followed by a refusal. Whichever way it goes, this is a decision for somebody with authority, on the day, and the plan should say who that is.

The incident you heard about is the one somebody was annoyed enough to report. Assume it is not the only one. Search the conversation logs for the same question in other phrasings, over the whole period since the material was last changed, and count.

Then widen the search by cause rather than by question. If the answer was wrong because a condition sat in a different paragraph from the rule it qualifies, every other question that reaches that page has the same defect. If it was wrong because two documents disagree, ask which other questions those two documents both match. One incident is usually a sample from a small family of incidents, and finding the family is the difference between a fix and a patch.

Where the affected people can be identified and the wrong answer had consequences, contact them before they contact you. That is uncomfortable and it converts a set of future complaints into one controlled message, which is a good trade in every direction.

The fix is almost always in the material, and the instinct is almost always to blame the model and add an instruction telling it to be more careful.

Go through the causes and see how few of them are about the model. A condition written two paragraphs away from the rule it qualifies. Two pages that disagree, one of them older. A price that changed on the website and not in the uploaded copy. A heading written in internal vocabulary so the right page never matched. An internal document that should never have been indexed. A table whose column headings did not survive being read. In every one of those the system quoted your material accurately, and your material said the wrong thing.

The reason this matters practically, rather than just philosophically, is that the two kinds of fix behave differently. An instruction is global, invisible and unverifiable: you cannot check it worked without waiting for the question to come back, and three of them added in one week produce behaviour nobody can attribute to anything. A material fix is local and testable. Put the condition in the same sentence as the rule and re ask the question. If the answer now carries the condition, you are done, and the page is better for human readers too.

There is one genuine exception. If the material is unambiguous, contains the condition, and the answer still contradicted it, that is not a content problem and no amount of rewriting will help. That is a threshold question, and the response is to make the system stricter about what it will attempt, accepting more refusals as the price.

Post incident enthusiasm produces five process changes, of which four are abandoned within a month and the fifth is the one that would have worked anyway. Pick one.

Choose it by asking which single change would have caught this specific incident. Sometimes it is an owner and a review date on a document that had neither. Sometimes it is an approval step before anything with a price on it gets indexed. Sometimes it is a rule that routes an entire category to a person. Sometimes it is simply removing a document that should never have been in there. One change, implemented properly, beats five announced.

And start an incident log, if there is not one. Four columns: what was asked, what it said, why the material allowed that, and what was changed. It takes a few minutes per entry and within a few months it is the most valuable document you have about your own content, because the same pages fail repeatedly and the log is the only thing that makes the pattern visible.

Do not turn it off as a reflex. A single wrong answer is evidence of a content defect, not of a failed channel, and switching off removes your ability to see the other defects. Turn it off when it is repeatedly wrong about things that matter and you cannot fix the cause quickly, which is a different situation and one you will recognise.

Do not add a disclaimer as the fix. A line saying answers may be inaccurate does not stop a customer relying on a price, does not help much in a dispute, and does tell every future visitor that the channel you paid for is not to be trusted. Fix the material, and set the threshold so it refuses when it should.

Do not make reporting harder. The natural bureaucratic response to an incident is a form, an owner and a triage step, and the effect is that the next wrong answer is not reported at all. The route to report one should be easier after an incident than before it, because the people best placed to notice are support agents in the middle of a conversation with somebody annoyed.

And do not stop reading conversations because you are now nervous about what is in them. That is the exact moment the reading is most valuable, and it is the moment teams most often quietly abandon it.