Foundations · Explore this field ↗ · Practice · 4 min read
Scope and refusal contracts: make a useful no repeatable
Publish what the service can do, where it stops, and the next route a person can actually use—then test refusals as carefully as answers.
Scope decision flow
- 01Identify request
- 02Check capability
- 03Complete or explain boundary
- 04Offer owned route
Conceptual routing, not a claim about model behavior.
Original conceptual diagram · not a live trace or measured result.A contract is more useful than a disclaimer
A capability contract is a short, testable description of the jobs a conversational service accepts. It names the user group, channel, inputs it can use, actions it may take, decisions it cannot make, and how a person can continue. Put the contract near the entry point and repeat the relevant boundary just before a consequential step. “I can explain the policy and open a review request; I cannot approve an exception” is more useful than “I may make mistakes.”
The contract is not a legal shield or a promise that every request will be understood. It is an operational interface between product, support, and the user. NIST frames AI risk management as work across design, development, use, and evaluation; this guide turns that broad framing into a small published artifact. A team should be able to point to every sentence and name the route, owner, and test behind it.
Write verbs, boundaries, and alternatives
Start with a job inventory. For each common request, write one allowed verb, the preconditions, the visible result, and a boundary. Separate “find an order” from “change an order,” and “draft an appeal” from “decide an appeal.” A boundary should be specific about the missing authority or evidence, not an accusation about the person asking. It should also state whether the system has taken no action, saved an uncommitted draft, or opened a case.
Then add an alternative that is real today: a secure account page, an approved form, a phone number with hours, a human queue, or a source link. Do not offer an alternative that merely repeats the blocked task in another box. If none exists, say that plainly and send the missing route to the service owner as a product gap. A contract that points people to a closed queue is worse than a direct limit.
Test refusals without moral theater
Build a refusal fixture for each boundary. Include a straightforward out-of-scope request, an ambiguous request that needs clarification, a user who insists, and a request that becomes in-scope after authentication. Assert the route, the explanation, the absence of invented policy, and whether the user can leave. Do not score politeness alone; score whether the next step is accurate, available, and proportionate to the request.
Worked example, hypothetical: a repair assistant can book an appointment only after a signed-in customer selects an address. A guest asks it to move tomorrow’s visit. The expected response identifies the missing signed-in state, offers the account route, and does not request a password in chat. A failed version lectures about security, then asks for the booking code and password anyway. The defect is the unauthorized collection path, not merely unfriendly wording.
Give operators a change path
Each contract row needs an owner, version, review trigger, and retirement rule. A newly connected tool, changed eligibility policy, or discontinued handoff route should trigger review before the service claims a new capability. Keep the public wording compact while retaining an internal capability matrix with dependencies, authorized data, action confirmation, and fallback. This makes the contract reviewable when product copy changes independently of engineering.
Success is not a low refusal count. It is that reviewers can correctly predict the route for sampled requests, users encounter a working next step, and a release cannot expose a capability without its controls. Track boundary mismatches as defects: accepted-but-unavailable, refused-but-permitted, and alternative-route failure. Review these separately by task and channel; a speech route may need a different handoff explanation from web chat.
Limitations and counterexamples
A published contract cannot safely enumerate every adversarial request, jurisdiction, or edge case. It also cannot replace access control, source governance, or a human decision maker. Keep it at the level of stable service promises and route unusual cases to an owned review path. The service should be able to say “I do not have enough verified information to decide that” without inventing a policy reason.
Avoid making scope so broad that it becomes marketing copy or so narrow that normal language is rejected. A useful counterexample is a service that says it “handles returns” but can only locate a return label. The repair is not a softer refusal; it is a corrected verb and a route for the actual return decision. Recheck the contract after incidents, source conflicts, and new accessibility needs, because these expose limits that a happy-path launch did not reveal.
Take it into the review
Capability-contract review sheet
| Request | Permitted verb | Boundary | Alternative route | Owner |
|---|---|---|---|---|
| Move an appointment | Submit change after signed-in confirmation | No guest changes | Account sign-in route | Service operations |
| Ask about eligibility | Explain current approved policy | No case decision | Review-request form | Policy owner |
| Request a person | Transfer or create case | No simulated live queue | Published support hours | Support lead |
A starting artifact to adapt to your service—not a ready-made policy, compliance certificate or test result.
Primary reading
Sources and limits
These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.
What the sources establish
AI Risk Management Framework
NIST describes the AI RMF as voluntary guidance for incorporating trustworthiness considerations into design, development, use, and evaluation.
Limits: The framework does not prescribe this guide’s contract fields or wording.
Checked 2026-09-19 · NIST · source publication date not established.
Open original source ↗Fulfillments
Dialogflow CX documents handoff and success signals whose data structure is left to the integration.
Limits: This documents one platform mechanism, not a universal scope-contract standard.
Checked 2026-09-19 · Google Cloud · source publication date not established.
Open original source ↗Procedures and worked examples are editorial synthesis. Preparation/review dates are not claimed historical publication dates.