Guardrails: Why Refusing to Answer Beats Guessing a Contribution Limit

The assistant that guesses a contribution limit serves the user worse than the assistant that refuses. The design question is how to make the refusal useful.

A financial assistant faces a class of questions where the honest answer is that it does not know. A tax-year constant it does not have a tool for. A jurisdiction it does not cover. A user input outside a model’s valid range. A compound question that requires a computation no shipping model performs. The tempting design choice is to produce a plausible answer anyway, because a plausible answer feels helpful. The tempting choice is wrong. The piece Approximation vs. Computation (/writing/approximation-vs-computation) develops the argument for why plausible answers are a specific kind of harm. This piece is about the refusal itself — what makes one useful, what makes one useless, and why the design work is worth doing.

What a bad refusal looks like

A generic refusal fails the user without helping them. I cannot help with that request. I am unable to answer questions about specific financial products. Please consult a professional. Each of these is a legitimate sentence in isolation and a failure in context. The user came with a specific question. The refusal does not name what specifically the assistant cannot do, does not name what the user could do instead, and does not distinguish between a legitimate scope limit and an evasion. The user is left with less than they started with; they now know the assistant cannot help and do not know why or where to go next.

A bad refusal is also indistinguishable from a policy dodge. Assistants sometimes refuse questions because a content policy said no rather than because the assistant lacked the tools to answer. The user cannot tell which happened. A design that treats both cases the same way collapses two different situations into one confused message, and users learn to distrust refusals in general because they cannot decode which kind they are receiving.

What a good refusal looks like

A good refusal names three things. The specific reason the assistant cannot answer. What the user could do to enable an answer. What the user should do if enabling is not possible. The three-part refusal is longer than a generic one and shorter than a full explanation. It respects the user’s time and preserves the user’s agency.

A concrete example. A user asks about the current-year contribution limit for a jurisdiction the assistant’s catalog does not cover. A bad refusal: I cannot help with that. A good refusal: our current model catalog covers United States tax constants; the jurisdiction you asked about is not included. For the current-year limit in your jurisdiction, the primary source is your national tax authority. If you are asking because you want to compare across jurisdictions, we can help with the United States side, and you can pair that with your national source. This response respects the user’s time by naming the constraint, respects the user’s intelligence by pointing to a workable path, and respects the assistant’s scope by not fabricating.

Refusals that come from validation

Some refusals originate in the deterministic model rather than the assistant. A user asks for a refinance break-even with closing costs above the model’s published domain; the model returns ok: false with the field and the rule — closing costs must be between 0 and 20,000 — a rejection, never a silent adjustment. The assistant’s job is to translate that structured error into a user-facing message that names the input, states the valid range, and asks whether the user meant a different value. A sentinel is a different thing entirely — not a refusal at all. A refinance into a higher rate returns an Infinity sentinel inside a successful response, with a triggered annotation: the computation worked, and the honest result is that the loan never breaks even. The assistant’s job there is to phrase an answer, not to apologize for one.

Validation refusals are the class the assistant handles best when the assistant’s prompt template is designed for them. Every model that can reject an out-of-domain input — and every model whose sentinel answers need phrasing — has a small set of user-facing messages the assistant should produce. Writing those messages in advance is design work; leaving the assistant to produce them on the fly produces variable-quality output where the same failure mode gets a specific response one time and a generic one the next. Consistency comes from advance authoring.

Refusals that come from scope

Other refusals come from the model catalog not covering a question. A user asks about a computation no shipping model performs. The assistant should not fabricate the computation and should not refuse generically either. The right response names what the shipping catalog covers, what it does not, and what the user’s options are: a specialist tool, a primary-source calculator from an agency, an advisor, or a manual computation the user could perform. Each is a legitimate path; refusing to name any of them treats the user as if the assistant’s scope is the world’s only option.

Scope refusals are where the roadmap surface becomes useful. If a computation is on the roadmap under a themed pack, the assistant can name that when it refuses. The user then knows the request has been heard and has an approximate answer to when the capability might exist. Naming the roadmap without a specific date is honest; committing to a specific date the roadmap has not published is not.

Refusals that come from safety policy

A third class of refusal originates from a caller-side content policy: the assistant refuses to answer because the request violates a policy the caller established. Personalized investment advice, jurisdiction-specific tax opinions, and predictive claims about specific securities are common examples. Policy refusals should look different from validation refusals and scope refusals, so users can tell them apart. Naming that the response is bounded by policy — not by capability — is more respectful to the user than merging the three refusal types into one message.

The design work is to author distinct patterns for the three refusal classes. Validation refusals name the input. Scope refusals name the catalog gap. Policy refusals name the policy. Sentinels stay off this list on purpose: a sentinel is an answer, and it gets an answer’s phrasing. Users who receive different messages for different situations calibrate their expectations correctly. Users who receive one generic message for all three lose trust in every refusal.

The specific harm the good refusal prevents

A user who receives a good refusal knows what to do next. A user who receives a plausible guess acts on the guess and may not discover the error until it has cost something. The specific harm of the plausible guess is not that it is sometimes wrong; the harm is that its wrongness is invisible at the moment of decision. A contribution limit that is off by a hundred dollars leads to an excess-contribution correction. A retirement projection that assumes a stale tax rule misroutes a Roth-versus-traditional decision. A refinance answer that ignores an out-of-range input misroutes a housing decision. Each of these is remediable but not costless; the good refusal prevents the sequence entirely by not producing the misleading answer in the first place.

“A refusal is not a limit. It is what the assistant does with the request instead of misleading. Design the refusal, or the assistant will produce one at random.”

Measuring refusal quality

Refusal quality is measurable. The three-part standard — names the reason, names what would enable, names an alternative — is either satisfied or not. Teams that grade a sample of refusals against the standard produce a score they can improve on. Teams that treat refusals as unmeasurable produce refusals whose quality is unmeasurable, which is a decision to not improve them.

A specific measurement discipline: take the last hundred refusals the assistant produced, mask user identifiers, and grade each on the three-part standard. Compute the percentage of refusals that pass. Address the specific failure patterns in the ones that did not. Repeat quarterly. The score should improve; if it does not, the refusal templates need work, and the templates need work by a person, not by another prompt tweak.

The refusal as a design surface

The best financial assistants treat refusals as a first-class design surface. The reply template that produces answers is designed. The reply template that produces refusals is designed. The audit surface behind both is designed. Design work applied to refusals is engineering work applied to the specific parts of the assistant that build trust the most and are most often left unaddressed. Assistants that survive careful users and careful reviewers do so because the refusals were designed with the same discipline as the answers.