A large language model has no natural edges — ask it anything and it will produce a fluent answer, in or out of its depth. A capability contract draws those edges for it: here's what this system is for, here's where it taps out, and here's what it hands back to a human. Set it before the first use — not after the first complaint. The limits of a generative model, named plainly up front, are what make the rest of it believable.
Declare the edges in the interface
Most products bury scope in a terms-of-service page and hope. Then the model gets a question outside its competence, answers anyway, and a user's trust dies in a single confident wrong answer. The fix is to state the boundary where the work happens — in the interface, at the moment of use.
An honest "I don't handle that" is not a weakness; it's the thing that makes the "I do handle this" believable. A model that knows its own edges reads as a colleague, not a slot machine.
Hand off; don't fake it
When a request leaves the model's competence, the right move is a clean hand-off to a human — visibly, not silently. The worst pattern is graceful-looking degradation: the model keeps answering, in the same confident tone, well past the point where it knows anything.
Design the hand-off as a first-class path, with the same care as the happy path. The person should feel routed, not abandoned — "this one needs a specialist, here's how to reach one," not a shrug.
Specific beats vague
"Results may vary" protects no one and informs no one. A real capability contract is specific: "I can't price illiquid assets," "I don't read handwriting," "I'm trained through 2024." Specific limits are the ones a person can actually plan around.
Specificity also disciplines the team building the thing. Writing the contract forces an honest conversation about what the model actually does well — and that conversation, more than any feature, is what keeps the product trustworthy as it grows.
Implementation Checklist
- Write the contract before launch: what it's for, where it taps out, what it hands back.
- State limits in the interface, at the point of use — not only in the docs.
- Make out-of-scope a clean hand-off to a human, not a silent confident guess.
- Be specific: name a boundary a person can plan around.
- Revisit the contract every time the model's scope actually changes.
A capability contract is a one-pager the whole team signs before launch. Fill in the brackets; delete nothing without deciding it.
CAPABILITY CONTRACT — [product / feature] Owner: [name] · Review date: [quarterly] IN SCOPE — this system is for: • [the job, stated narrowly: "score deal risk from the data room"] DECLINES — it says "I can't" when: • [named limit: "the claim can't be grounded in a source document"] • [named limit: "confidence falls below the abstention threshold"] HANDS OFF — out-of-scope requests route to: • [the human/team + the handoff surface] NEVER — even if asked: • [the hard line: "state a figure without a citation"] WHAT WE TELL THE USER — in the interface, not the docs: • [the sentence on screen: "I can't price illiquid assets."]
See This Pattern In Action
- Programmatic Advertising Platform: every call resolved to act, review, or ignore — "ignore" was the model admitting it had nothing worth saying.
- AI-Assisted Due Diligence: the model declared the deals it wouldn't score, up front, instead of bluffing through them.
One pattern a month. The tradeoffs I paid for, plus the templates I use.