PTN—26
Showing limits
State what the system cannot do — scope, staleness, blind spots — before people discover it by failing.
Every AI system has edges: a knowledge cutoff, domains it handles badly, tools it lacks, data it cannot see. The only choice is who finds the edges first — the design, or the user, mid-task, at cost. Showing limits is the practice of surfacing boundaries proactively: naming the cutoff when recency matters, declining out-of-scope requests with a redirect, admitting when the system can’t see the thing being asked about. Microsoft’s HAX guidelines open with exactly this pair: make clear what the system can do, and how well.
The counterintuitive part is that stated limits increase trust in everything else. A system that says “I can’t access your billing data — here’s the link” earns belief for the claims it does make, because the person has evidence it knows the difference. A system that bluffs past its edges converts every failure into evidence that no answer can be trusted. Honesty about the 10% you can’t do is what makes the 90% credible.
Placement is the craft. A limitations page nobody reads does nothing; a wall of caveats before every answer does worse. Limits belong at the moment of relevance: the cutoff disclosed on the question about last week’s news, the “I can’t see images in this mode” at the image upload, the scope boundary at the out-of-scope request. Contextual, specific, once — not global, vague, always.
When to use
- The system has a knowledge cutoff and people will ask about events after it.
- Capability is uneven across domains, languages, or file types in ways people won’t predict.
- The AI lacks access to context people assume it has — their account, their screen, their data.
- A request is out of scope and silence or a bluffed answer would be worse than a redirect.
Design considerations
- 01Disclose the limit at the moment it becomes relevant, not in a global disclaimer.
- 02Be specific: “my training data ends in early 2025, and this changed since” beats “I may not have current information.”
- 03Pair every stated limit with a path forward — search the web, upload the file, contact a human.
- 04Decline out-of-scope requests crisply instead of producing a degraded answer that looks like a real one.
- 05Say “I don’t know” as a first-class response state with its own design, not as failure text.
- 06Keep the capability story consistent between marketing and product — the interface pays the trust debt the landing page runs up.
- 07Update disclosed limits as the product evolves; a stale warning about a fixed limitation erodes trust in the true ones.
Pitfalls
- ✕Bluffing past the cutoff: answering “what happened this week” from stale training data in a confident voice. One caught instance and the person re-checks everything, forever.
- ✕The disclaimer wall — global, vague caveats on every response that train people to scroll past all warnings, including the load-bearing ones.
- ✕Capability mismatch between marketing and product: the landing page promises “knows everything about your business,” the model can’t see last month’s invoices, and the interface inherits the broken promise.
- ✕Hiding limits to protect the demo. The edges get discovered anyway — in production, by paying users, framed as dishonesty instead of scope.
In the wild
- Claude
- Names its knowledge cutoff when a question is time-sensitive and flags when an answer may be stale rather than silently asserting it.
- ChatGPT
- Distinguishes answering from training data versus browsing, and says when it needs to search because a question exceeds what it knows.
- Perplexity
- When retrieval comes up thin, says the sources don’t cover the question instead of padding a synthesis from nothing.
- Cursor
- Surfaces what context the model can actually see — attached files, codebase indexing state — so “it can’t see that file” is inspectable rather than mysterious.