Respond safely when the bot cannot answer
Make every unsupported, invalid or broken path return an honest and useful state without inventing information or leaking internals.
01 · Understand
Why this issue exists
“I cannot confirm that from the approved sources” is a valid product result, not a failure to hide.
02 · Investigate
Break-it lab
Five ways not to answer
The input may be empty, malformed, unsupported, matched to incomplete evidence or interrupted by an unexpected service error. One generic “something went wrong” message does not help in all five cases.
- 1What should the user do next in each state?
- 2Which failures are expected and which are exceptional?
- 3What technical details must never appear?
- 4What privacy risk is created by logging the raw question?
03 · Decide
How should the outermost public service boundary behave?
04 · Make the thinking visible
Team workspace
Discuss first, then record the team’s reasoning. These notes stay in this browser until you copy them.
For each reason code, write the user need, safe message purpose and next action.
List at least five synthetic inputs or injected failures and their expected safe results.
What may be measured without storing the customer’s raw question?
05 · Scaffold
One public entry point that never raises
Handle expected states explicitly. Reserve the broad catch for the outermost boundary and return a typed result rather than UI text.
def answer(question: str) -> Answer:
try:
# Validate → authority → search → evidence → answer
...
except Exception:
# Return a deterministic safe result.
# Never include the exception or raw question.
...06 · Prove it
Evidence checklist
Tick an item only when the team can show the evidence and another student can explain it.
Push further
Stretch challenge
Create one failure that occurs deep in the service. Confirm that the interface receives the same safe contract as every other state.