What a robot cannot do matters as much as what it can do
Aliases: capability limitation · operating envelope · negative capability
What it is
Capability boundary communication explains both reliable tasks and the objects, environments, speeds, permissions, or uncertainty under which execution should not occur. A feature list describes successful territory; limitations let people judge whether a new case remains inside the operating envelope.
Why it happens
People generalise from success, while marketing and demonstrations sample the centre of the distribution. A limitation buried in a manual is absent from working memory at delegation. Linking limits to action, sensing, and environmental conditions turns “it cannot” into a diagnosable domain rather than random failure.
Studying it
Participants can delegate across nominal and boundary cases, measuring correct refusal, over-reliance, under-use, and transfer after failure. Recall of limitation text is distinct from applying it. Cases should come from field logs and engineering failure analysis rather than researcher imagination alone.
Where it stops holding
No inventory covers every rare case; boundaries need generalisable variables and triggers. Software, payload, and environment change capability, making static notices stale. User comprehension never transfers the provider's safety responsibility to the user.
Applying it
- State capability through object, environment, action, and confidence conditions, including prohibited conditions and safe alternatives.
- Surface the relevant limitation at delegation rather than only during onboarding.
- Test unseen boundary cases, tracking inflation, under-use, and persistence of old models after updates.