05Building the answering side
An answer, a pointer or “I don’t know”: the torque example turned into a specification.
The answering side has one job: produce the right response. That is not always an answer. It is one of three outcomes: an answer with its source, a pointer to the source, or "I don't know" with the name of someone who does. Choosing among them is a behaviour to be designed, tested and owned like any other.
The torque example as a specification
A technician asks at what torque a bolt must be tightened on a given locomotive. Three cases follow (Figure 5). If the model is identified and the value documented, the system gives the value and its exact source. If the model is identified but no value exists, it says so and names an expert. A gap recorded by the knowledge base makes this case certain. Without one, failing to find a value is ambiguous: the value may be missing, or the search may have missed it, and that doubt is a reason to point, not to answer. If the model cannot be identified but values exist for similar ones, the tempting behaviour is to give the nearest model's value, fluently and confidently. That is the most dangerous thing the system can do, and the design must make it impossible, not merely unlikely.
General rules follow
No value without a source. A confidence threshold below which the system declines. For questions classified as safety critical, a stricter path where only validated sources count, or where the system points to the document and never answers directly. The same discipline applies to figures: when the system queries financial data, it shows which definition and which period it used.
What the answering side may show, and to whom, is the subject of the next chapter.