Ultra PatternsAI interface patterns with receiptsULTRA project

Pattern 13 · Chat or assistant · Interaction pattern

View

Out-of-scope refusal with a next step

Seen in a case Built for a real case and observed with its users, or built for a case whose user test is still to come. No controlled comparison yet.

Practice view. What to build, the words on screen and how to measure it. Switch to Research for why it should work, the framework properties and the references.Research view. The research side is shown below the card: why it should work, the properties it targets and the references. Switch to Practice to hide it.

A refusal state with fixed wording: what the assistant is not trained for, where to turn instead (a person, a service, a helpline) and what it can still help with. Entering that state is a code decision on a scope flag, never left to the model's judgement of the moment.

WhyA boundary that moves reads as a malfunction. In Goose's second test three of four participants found the scope control clearly better than before, and one bug showed the flip side: one participant got the helpline, another in a similar situation did not.
WhenAny assistant near health, money, law, safety or wellbeing, and any chatbot people are likely to test with edge cases.
Not whenGeneral assistants where refusals would be constant. Narrow the product instead of decorating a refusal.

The right amount of trustThe system shows how it worksCase: Goose conversation guide

Done right, done wrong

Schematic screens, not real products. Click a screen to enlarge it.
Right. The limit in plain words, a helpline, and what the assistant can still do. Replace the helpline with the one for your users' country before you ship.
Wrong. A vague refusal without a next step; the same question elsewhere gets a different answer.

In practice

Goose’s refusal screen for a crisis message says three things: I am not trained for this, here is the suicide prevention line and the emergency number, and here is what I can still do, such as suggesting a warm and supportive reply that asks whether the friend is safe. Three of four participants found the scope control on sensitive topics clearly better in version 4 than in version 3.

The bug is the lesson. In two comparable sessions one participant saw the helpline and the other did not, a bug in the refusal state. The team made that the first item of its action plan, above every usability fix, because it touches both the safety claim and the architecture claim. If you build this pattern, the refusal wording lives in code, the trigger is a flag the code evaluates, and a test sends the same message twice and expects the same screen.

Words on screen

"I am not trained to help with thoughts of suicide. In Belgium you can call the suicide prevention line on 1813 or go to zelfmoord1813.be. If you are in danger right now, call 112.""What I can still help with: a warm, supportive reply.""This is outside what I can do. A person from the team can help you."

Obligations to keep in mind (AI Act, GDPR)

  • Name the limit in plain words. A bare 'I can't help with that' reads as a malfunction. (O1, IUI 2026, Table 1)
  • The refusal must be deterministic and logged. Test it by sending the same scenario twice. (O2, Goose v4)

Design considerations, not legal advice or a conformity assessment. What O1 to O5 mean.

Build it

Illustrative signatures, not a published library: the names below are suggestions to adapt to your stack. Thresholds are examples to tune on your own data.

States: in-scope, refused-crisis, refused-scope, redirected

Component: <Refusal reason="crisis" nextSteps={[helpline, person]} stillCan={[reply]} />

Prompt snippet: If the message is out of scope, set out_of_scope to true with a reason. Do not answer the request.

Output schema: { "out_of_scope": true, "reason": "crisis | medical | legal | other" }

Measure it

Users rely on it the right amount · 10 minCatching made-up facts · 6 minPlan your testTen minutes per participant is the usual budget: pick the two or three cards that fit.

Same idea, other names

Research side · why it should work

Why it should work

The mechanism, notes and references for this card are written together with the science editor at KU Leuven Augment. Until then this side lists the properties the pattern targets and the contexts in which it was seen.

Properties targeted

Trust · Reliance · Axes: type: refusal, format: text, interaction: system-triggered · Vocabulary bridge

Across contexts

ContextUsersStateResult
Goose conversation guide, v4adults, mobileSeen in a casescope control judged clearly better by 3 of 4; helpline shown inconsistently (bug, first priority in the action plan)
Your contextBring your case

Editors

Practice: Rutger De Wilde (Odisee UX Lab) · Science: to be assigned by KU Leuven Augment · card v1.0 · 2026-09-03