AI that doesn't know your business makes things up.

In plain terms: this section is about how we stop the assistant from confidently telling your customers things that are not true. A language model's default behaviour is to produce a plausible answer. It has no internal signal that separates 'I retrieved this' from 'this sounds like the kind of thing that would be true', and the output looks identical either way. That is the whole risk: a wrong answer arrives with the same confidence as a right one, and the customer cannot tell. So the engineering problem in DockAI is not making it answer. It is making it refuse.

Refusal cannot be achieved by asking. A prompt that says 'only answer from the provided context' works most of the time, and most of the time is not a standard — it means the failure is rare, which means it is unmonitored, which means the first person to find it is a customer. So grounding is enforced structurally: the retrieval step runs first, and if nothing clears the relevance bar, the generation step is not reached. There is no path from an ungrounded question to an answer, because the path does not exist rather than because the model was asked not to take it.

That pushes the difficulty into retrieval, which is where it belongs and where it is tractable. Most RAG systems fail here quietly: chunk on a fixed token count and you cut a policy in half, so the passage answering the question is now two passages, each individually irrelevant. We chunk on the document's own structure, keep the heading path with the chunk so a fragment knows what it is a fragment of, and retrieve wider than we generate. The relevance threshold is then a real decision with a real cost, tuned per deployment against questions with known answers — and tuning it is how an organization chooses, explicitly, how often it would rather say nothing than risk being wrong.

Actions are the same argument with higher stakes. An assistant that answers wrongly costs trust; one that acts wrongly costs money. So tools are permissioned individually and split by consequence: reading an order status is not the same class of thing as issuing a refund, and the system does not let a persuasive conversation collapse that distinction. Anything with a consequence a customer cannot reverse routes to a person.

Handover was the last thing to get right and the most visible. An assistant that fails to a human who then asks 'how can I help you today' has wasted the customer's time twice. The transfer carries the conversation, the passages retrieved, and what the assistant already attempted — so the person opens with context rather than with a question the customer has already answered.

The unexpected outcome is that the refusals became the product's most valuable output. Every question the assistant could not ground is either a hole in the organization's documentation or a thing it has decided not to talk about. Collected and reported, that list is a to-do list written by customers — and organizations act on it in a way they never act on a generic content audit.