Case study · Proxy
Side projectProject period2026 – Present
Designed to fail safely
Gave every failure a defined outcome: keyword rules take over if the router model fails, a fixed sentence replaces an empty model reply, canned answers handle abuse and private-life questions without any model call, and the widget shows a clear state when a limit is hit.
01
Why
Every part of the path can fail: the router can stall, the model can return nothing, a visitor can ask something the assistant must not answer, a limit can be reached. A blank or strange reply is the worst outcome for a visitor and a risk for me.
02
Decision
Each failure has a defined outcome. If the router model fails or times out, keyword rules take over. If the model writes nothing, a fixed sentence replaces it, and for a widget that sentence now names what the widget shows. Greetings, abuse, private-life questions and off-topic questions get a fixed reply with no model call at all. When a limit is reached the widget shows a clear state with a copy-the-email option instead of an error.
03
What I built
Gave every failure a defined outcome. Keyword rules take over if the router model fails, a fixed sentence replaces an empty model reply, canned answers handle abuse and private-life questions without any model call, and the widget shows a clear state when a limit is reached.
04
Trade-offs
- Fixed replies are less natural than a model's.
- The keyword fallback is less accurate and sends more context.
- A fallback sentence is generic next to a written one. I measured how often a widget answer arrived without a sentence and tightened the fallbacks, but the model writing its own sentence is still better.
05
Outcome
No blank replies, no raw errors, and every failure path has a test.
Technologies
- Fallback Design
- Guardrails
- Resilience