What the system cannot do needs stating as much as what it can

What it is

A product page lists “write mail, edit code, read tables.” It rarely lists “cannot testify in court, cannot sit a medical shift, cannot guarantee that a citation is real.” People extrapolate from the positive list; blanks get filled with “probably that too.” Negative capability disclosure puts what the system specifically cannot do on the same layer as the positive list, not in a disclaimer appendix.

The can-do list already has authors in marketing. This entry is the half nobody wants to write.

Why it happens

Affirmative descriptions are read as a floor, not a ceiling. “Can summarise a contract” does not, in language, exclude “can give legal advice” unless legal advice is named as cannot. Category induction then pulls neighbouring tasks in: can write mail becomes can handle an escalation; can read a table becomes can keep the books.

Empty states and examples only show success paths, so negative space has no visual seat. People are not ignoring a boundary. The interface never treated the boundary as an information object. Waiting for failure to teach pays the cost in a wrong action already taken.

Studying it

Two capability statements: a positive list only, versus the same list plus three explicit cannots. Then ask whether the system will do a set of unmentioned neighbouring tasks, and whether those tasks should be handed over. Independent variables: concreteness of the negative items (“does not give legal advice” vs. “results may be inaccurate”), semantic distance from the test tasks. Dependent variables: scope of extrapolation, mistaken handover, time spent reading the statement.

A universal “results may be inaccurate” does not count as negative disclosure. It points at no task and cannot shrink extrapolation.

Where it stops holding

An open-domain assistant cannot finish a cannot list; it has to be layered by consequence. High-stakes classes (medical, legal, financial action) must be named; the long tail of low stakes can wait for a local notice at failure. Children and other vulnerable users understand negative sentences less well than positive examples, so disclosure does not replace a block. This entry only argues that cannot has to be written as information. It does not require the whole list to be read on first open, and it does not treat version drift.

Applying it

• Give “will not” its own block in the capability statement, empty state, and first-run, beside “will.” Do not bury it in clause seventeen.
• Negative items must land on a task class: will not diagnose, will not send external mail, will not change production data. Ban a lone “may be wrong.”
• When a user walks into a named cannot zone, block and point back at that negative line, rather than generating an answer that sounds like can.
• Check: take the statement to someone new to the product and ask “will it file a complaint with your bank?” If complaint is on neither list and the answer is “yes,” negative space is being silently filled.

Related

• Same group: L1.02.2 Boundaries should be told before the attempt, not after the failure · L1.02.3 Boundaries change with versions; the statement must update with them
• Nearby: L2.01 Openness of natural-language commands and its cost · L2.09 Discoverability of what I can say · L5.05 The moderation principle of transparency
• Search terms: negative capability disclosure · known non-capabilities · capability boundary