BAA 101 · Chapter 06
Refusal is a state
The principle
Refusing is a normal answer from the system, not a silence or a crash. A RefusalAn explicit "I can't answer": no citation, zero confidence, human review. A state, not a crash.See in the glossary → has a shape, a reason, and it comes as early as possible.
Why it matters
A Silent failureAn error that looks like a normal answer, like "no results" when there are some. The worst kind of error.See in the glossary → looks like a real answer. A crash shows the user a technical error. A late refusal spends calls for nothing.
The mechanism
- Refuse before calling the model when nothing backs the answer: an empty search costs zero calls.
- An outage becomes a readable refusal: an exceeded TimeoutA maximum waiting time. Past it, you abandon the call and return a readable refusal, instead of waiting forever.See in the glossary → or a silent provider give a normal answer, and the technical cause goes into the TraceThe log of a run: every step (search, model call, tool call, decision) with its arguments and result.See in the glossary →.
- An empty or invalid input is refused explicitly, never silently ignored.
- A useful refusal names what’s missing, in figures: the field, the value asked for, the value found.
- A refusal is flagged for human review. And you also measure the other risk: refusing what you could have answered.
In the field
- Dev3Pack, Session 2: if the model doesn’t answer, the user reads “The model did not respond.”, with a timeout set to 3 s after measuring.
- Dev3Pack, Session 3: an off-CorpusThe set of documents the agent is allowed to rely on.See in the glossary → question is refused without any model call.
- Dev3Pack, Session 6: a file without a title is refused, rather than returning half a document.
- Dev3Pack, Gecko: “two espressos” is refused on quantity, naming both values (2 asked, 1 prepared), and nothing is signed.
The question to ask
When this system can’t answer, what does the user see, and what did it cost?