Why we built an AI that refuses to answer

The easy thing to build

Give a language model a company's documents and it will answer almost anything you ask it. That is the product most teams ship, and it demos beautifully. The failure only shows up later, in a live process, when somebody acts on an answer that was assembled from whatever the retriever reached first.

The uncomfortable part is that the model is not malfunctioning when this happens. It is doing exactly what it was built to do: produce the most plausible continuation. Plausible is a different thing from verified, and in a regulated process the distance between them is where the cost sits.

So the first design decision we made in MindKeepr was a refusal. When a question cannot be answered from knowledge somebody has verified, the system does not answer it.

Absence is a different problem from search

Every retrieval tool in this category is measured on how well it finds what exists. Precision, recall, ranking quality: all of them assume the answer is in the corpus and the job is to surface it. None of that machinery can report that something was never written down, because there is no document to rank.

Language models inherit the same limit in a subtler form. A model can tell you it is unable to answer a specific question. It cannot tell you that an important piece of operating knowledge has never been captured anywhere in your company, because detecting that requires something to compare the corpus against.

This is why we treat a failed question as a first-class object rather than a dead end. A question that the organisation could not answer is the cheapest, most honest signal of a gap you will ever get. It needs no process map and no reference model. Somebody needed to know something, and the company could not tell them.

What the product does instead

When MindKeepr meets a question that nothing verified can answer, three things happen. The question is kept as a tracked item rather than discarded. The system names the specific thing that is missing, not merely that something is. Then the question is routed to a named person, with a deadline.

That middle step matters more than it sounds. There is a large difference between telling a manager that knowledge coverage in claims handling is weak, and telling them that nobody has ever recorded the threshold at which an exception needs a second approver. The first is a dashboard. The second is a task somebody can finish this week.

What the system does not do is write the answer. There is no summariser and no model sitting on that path, by design. Producing prose for a governance surface would put words in front of a verifier that nobody actually wrote, and the moment that text is approved it becomes company fact.

Why we do not nominate the verifier

An obvious feature request is for the system to say who should verify each gap. We deliberately do not, and the reason is separation of duties rather than modesty about our own inference.

The person the system would most confidently nominate is whoever is closest to the question, and that is usually the person already being asked to answer it. A product that quietly proposes the answerer as their own approver has built a separation-of-duties violation into its happy path, and any auditor who understands the control will find it.

So routing and approval stay two different decisions, made by the organisation. The question goes to a person. Someone else, holding the authority for that kind of knowledge, decides whether the answer stands.

From an answer to company memory

The person who knows writes the answer in their own words. It arrives as a candidate, not as published memory, and the approval queue shows what they actually wrote rather than a paraphrase of it.

Somebody with the authority to confirm it then approves, and the approval binds to that exact version of the text. If the underlying content changes later, the review reopens rather than the old approval quietly carrying over. A stale approval is worse than no approval, because it certifies with full confidence something nobody reviewed.

Only after that does the answer become available to people and to the AI agents the organisation has approved, carrying who declared it, when, and what it was based on.

What the refusal costs, and why we keep it

This is slower than generating a guess. It asks something of a human being, which is the one resource every knowledge product is tempted to spend freely and the one that decides whether the system survives contact with a real company.

We think that cost is the product. Microsoft retired Viva Topics in February 2025, and the lesson worth taking from it is not that the AI was weak. It is that a system which asks people to confirm a large pile of machine-generated candidates will run out of goodwill before it runs out of candidates.

So the design question is not how much a model can find. It is how little you can ask of a person and still end up with knowledge that somebody stands behind. Our answer is one specific question, to one named person, at the moment the work actually needs it.

• ✓Retrieval tools are scored on finding what exists, so none of them are built to report absence.
• ✓A confident answer to an unanswered question is the expensive failure mode in a live process.
• ✓Naming what is missing is a stronger claim than reporting that something is missing.
• ✓Separation of duties means the system should not nominate the verifier: the obvious candidate is the person already asked to answer.
• ✓An approval is only meaningful if it is bound to the version of the text that was approved.

FAQ