PTN—03
Capability disclosure
Honestly communicating what the system can and cannot do, before the person finds out the hard way.
Every AI interface makes a promise, and the open text box makes the biggest one: ask anything. When the system then fails at something it appeared to offer, the person does not file the failure under “edge case” — they downgrade their model of the whole product. Capability disclosure is the practice of scoping the promise up front: naming what the system does well, what it does not do, and where its knowledge ends.
Microsoft’s HAX guidelines put this first for a reason — “make clear what the system can do” and “make clear how well it can do it” are guidelines one and two. The interface carries this, not the docs. Model names and knowledge-cutoff dates, tool availability shown in the composer, scope statements on specialized assistants (“I can answer questions about your billing account”) all constrain expectations at the moment they form, which is the only moment that matters.
The failure mode on both sides is real. Underdisclosure produces the trust cliff: a person burned once by a hallucinated citation stops trusting correct answers too. Overdisclosure produces the timid product buried in disclaimers nobody reads, where a wall of caveats is functionally identical to none. The craft is placing one specific, relevant boundary at the point of use — a cutoff date next to a dated answer beats a paragraph of legalese under the composer.
When to use
- The system has hard boundaries — knowledge cutoffs, unsupported languages, no web or account access.
- A scoped assistant risks being mistaken for a general one, or vice versa.
- Users repeatedly attempt tasks the system fails at, then churn.
- Capabilities differ by plan, model, or mode, and people cannot tell which they are in.
Design considerations
- 01State the scope in the assistant’s introduction in one plain sentence — what it covers and the nearest thing it does not.
- 02Show the knowledge cutoff where recency matters, next to the answer, not just on a settings page.
- 03Expose available tools (web search, file access, code execution) in the composer so the promise is inspectable.
- 04When refusing or failing, name the boundary that was hit and point to what would work instead.
- 05Keep each disclosure to one boundary at its point of relevance; never stack caveats into a disclaimer wall.
- 06Update disclosures when capabilities ship — stale “I can’t browse the web” copy on a product that now can is its own honesty failure.
Pitfalls
- ✕The permanent tiny disclaimer (“AI can make mistakes”) doing all the safety work while the UI implies omniscience.
- ✕Scoped bots that answer out-of-scope questions badly instead of saying the question is out of scope.
- ✕Capability claims written by marketing that the model cannot cash, converting every gap into a broken promise.
- ✕Disclosing limits only in onboarding, which people skip, and never at the moment the limit bites.
In the wild
- ChatGPT
- Displays “ChatGPT can make mistakes. Check important info.” beneath the composer, and the model picker exposes different capability tiers by name.
- Claude
- Volunteers its knowledge cutoff when asked about recent events and states uncertainty about post-cutoff developments rather than guessing silently.
- Perplexity
- Frames itself around live web search with visible sources, making the capability claim — current, cited answers — inspectable in every response.
- GitHub Copilot
- Positions itself as a suggestion engine whose output requires review, and its documentation is explicit that generated code may be incorrect.