Testing the edges: refusals and house manners

The failure that costs professionals the most

For most people, the expensive problem is not that a tool will answer something dangerous. It is that it will refuse something ordinary.

A nurse asking about a drug interaction. A lawyer asking about the elements of an offence. A security engineer asking how a particular attack works so they can defend against it. A social worker drafting a safeguarding note. A researcher asking about self-harm statistics. A parent asking a medical question about their child. Every one of these is a legitimate professional or personal need, and every one of them sits near a boundary that products police differently.

These are false refusals, and they vary enormously between products running the same model, because the refusal usually lives in the product’s instruction layer rather than in the weights.

Put one at the edge of your field into the file

Prompt eight in your twelve is the one that sits near your professional boundary. Write it as you would ask it, with the context you would give. Then watch for four outcomes:

1. Answers usefully. Good.
2. Answers with a caveat. Usually the right behaviour, and worth preferring over a bare answer for medical and legal material.
3. Refuses, but explains and offers a route. Acceptable. It tells you where the wall is.
4. Refuses flatly, or moralises. This is the one that will waste your time repeatedly.

The difference between products on this is large and it is not correlated with model quality. A more capable model inside a more cautious product is less useful to you than a weaker one inside a product that trusts its users.

The other direction

Test it too. If you work with young people, or you are choosing a tool for a school or a family, probe what it does with a question a fourteen-year-old might ask about a dangerous topic. If the answer is unguarded, that is a real finding about a real risk, and it belongs in the decision alongside everything else.

Do not construct harmful requests to test this. You are checking behaviour at the boundary, not trying to extract something. A realistic edge case tells you what you need to know.

Stating context changes the answer

One practical technique, and an honest note about it. Explaining your role and purpose (”I am a district nurse; I need the interaction profile to counsel a patient”) frequently converts a refusal into a useful answer. The product cannot verify the claim, and that is a known weakness of the whole approach: the same sentence works whether or not it is true.

Two consequences worth holding at once. If you have a legitimate reason, say it plainly, because it works and it is honest. And do not mistake a system that can be talked round for a system that is checking anything, whether you are relying on it to protect your users or planning what to put in front of children.

Refusals move between versions

One more reason to keep this in your file rather than in your head: refusal behaviour changes more often than capability does. Companies tighten a boundary after a bad news story and loosen it after user complaints, and neither event comes with a release note that says so. A tool that refused your professional question last year may answer it now, and the reverse happens just as often.

That makes the boundary test the single item in your file most worth re-running at the six-month check, and it is also the one that most often changes the decision, because a tool that started refusing a category of question you ask daily has become unusable for you regardless of how it scores everywhere else.

House manners, which are separate

While you are at the edges, note the ordinary behaviours that will either fit your working life or grate on it every day:

• Does it ask a clarifying question, or guess? Both are defensible; only one suits you.
• Does it hedge everything, or commit?
• Does it apologise at length when corrected?
• Does it pad with preamble before answering?
• When it does not know, does it say so?

None of these appear on a benchmark. All of them determine whether you are still using the tool in six months. They are the strongest argument for testing yourself rather than reading a review: a reviewer’s irritations are not yours.

Write your findings on one line in the file. ”Refuses drug-interaction questions even with role stated; competitor answers with a caveat” is worth more to your future decision than any score out of twenty-four.