How do you design an LLM refusal so it isn't a dead end for the user?

## Why this is a design question, not a copy question Guardrail work is usually scoped as "stop the bad output". That scope ends at the moment of blocking, and everything after it — what the user sees, what they do next, whether they get their actual need met — falls between teams. The result is familiar: a correct refusal that produces an abandoned session and a support ticket. A senior answer treats the blocked path as a first-class product flow with its own design, metrics and owner. ## What the refusal message should contain **A category, not a rule.** "I can't give legal advice" tells the user what class of thing is unavailable so they can redirect themselves. Quoting the policy verbatim, naming the rail, or surfacing a classifier score does two bad things: it reads as machinery rather than help, and it hands anyone probing the system a precise description of the boundary to work around. Vague-but-honest beats specific-and-revealing. **No apology theatre.** Repeated apology text makes the system feel broken. One clear sentence is better than three hedged ones. **A next step.** This is the part that is usually missing. The question behind a blocked request is almost always legitimate — a driver asking a medical question has a real problem, and a competitor comparison is a purchase question. Route to the sanctioned surface: emergency services, roadside assistance, a human agent, a documentation page, the dealer. ## Carrying state across the handoff The difference between a refusal that works and one that annoys is whether the user has to start over. If an in-car assistant declines a medical question and offers roadside assistance, that handoff should arrive with location, vehicle identity and the fact that the driver reported feeling unwell already attached. Two design consequences follow. First, the blocked turn needs access to session state, which means the refusal path cannot be a bare string returned from deep inside a rail — it needs to be an event the application handles. Second, you now have a data-handling decision: what part of the blocked utterance may be carried into the handoff, given that it was blocked precisely because of its content. Answer that deliberately rather than forwarding the raw text. ## Hard block versus soft steer Not every rail should terminate the turn. Three responses are worth distinguishing: - **Hard block** — a line you will not cross regardless of phrasing. Refuse, route, log. - **Soft steer** — the request is near a boundary but likely fine. Answer the permitted part and name what you left out. "I can tell you the recommended tyre pressure; I can't advise on whether your insurance covers it." - **Clarify** — the request is ambiguous and the rail fired on a plausible reading. Ask one question. A large share of apparent violations are innocent phrasings, and clarification recovers them at low cost. Collapsing all three into a hard block is what makes guardrailed assistants feel hostile. ## The false-positive problem Every rail has a false-positive rate, and it is invisible by construction: the user who was wrongly refused does not file a bug, they leave. Instrument it. Log each block with the rail that fired, a correlation id, and enough context to review; sample blocked turns for human review; and watch abandonment immediately after a block as the leading indicator. Over-blocking is a product outage that never pages anyone. Track the two directions separately — a rail that never fires is either unnecessary or broken, and a rail that fires on five percent of legitimate turns is costing you more than the harm it prevents. ## Consistency across surfaces If voice, app and web refuse the same request differently — one with a route, one with a flat no, one by answering — users notice and trust drops. Refusal copy and routing belong in one place, versioned with the policy that triggers them, so a policy change updates the message and the handoff together. ## The line worth saying out loud A guardrail's job is not to end conversations; it is to keep them inside the boundary. Judge the rail by whether the user's underlying need was met through a permitted path, not by block count. Block count going up is not a success metric.