Openness makes functions non-enumerable; the product can no longer show a complete capability list

What it is

A settings page can list twenty switches because the switches were built in advance. Once open generation is wired to “call arbitrary combinations in language,” the product loses a finite feature table: non-enumerable capability. The list is not merely too short. The set of legal requests explodes combinatorially, and any finite list commits both errors at once — omitting what it can really do, and implying that what is off-list does not exist.

An entry that fails to cue range is a single field’s affordance failure. This is a catalog problem at product scale: marketing pages, pricing tiers, permission matrices, accessibility statements — every surface that once ran on a feature list — lose a closed extension.

Why it happens

In conventional software, a feature is a procedure bound at development time: a code path earns a menu item, and the menu is the extension. Language models defer the procedure to inference time. The extension becomes the reachable closure of the training distribution and the tool interfaces, a closure even the product team cannot see. Double ignorance follows: users do not know what they can ask, and the team does not know what to promise.

Once written, a list acquires normative force. What is written is read as a service level; what is unwritten is read as a defect. An open system that forces a list constrains an infinite set with a stale finite one, then apologizes at the edges forever. Without a list, pricing, procurement, and compliance audits lose their handle — the buyer asks “what features do you actually have,” and the seller can only say “it depends how you ask.”

Studying it

Show new users, procurement decision-makers, and support staff three artifacts: a conventional feature list, a page of example tasks, and a fully open description. Ask them to draw the capability boundary and decide whether to buy or to hand work in. Independent variables: list form (exhaustive table / task samples / no list), whether the list notes “unlisted does not mean impossible.” Dependent variables: boundary accuracy, over-promising (drawing in what cannot be done), under-promising, decision confidence and later regret.

The reference is the real tool-call graph and eval-set coverage, not advertising sentences on a model card. Internally, have the team list a hundred things they can do with eyes closed, then hit that list with long-tail requests from production logs — the length of the tail is itself evidence of non-enumerability.

Where it stops holding

Single-domain products (only certain contract clauses, only line charts) cage generation inside a closed task, and enumeration becomes possible again; openness is surface syntax. Enterprise builds that policy-disable tools turn the set finite once more, and the list can return. Plug-in markets or arbitrary URL tools bankrupt enumeration outright; even examples go stale. This entry does not treat what an empty box looks like. It treats the failure of the genre “complete capability list.”

Applying it

• Drop the “complete features” page. Group sample tasks by family, and say the samples are a slice, not the set. Route pricing and permissions through task families or tool switches, not a menu pretending to be exhaustive.
• Give internal teams and buyers a “we explicitly do not do this” list. Negative enumeration is more stable than positive: the cannot-do set grows slower, and compliance can hold it.
• New task families in production logs must flow back: the sample page updates from real use, not from release notes.
• Check: people new to the product, working from the public capability copy, list five cans and five cannots. Score against current tools and refusal policy. If the cans include things you explicitly refuse, or the cannots are all high-frequency successes in your logs, the list genre is already lying.

Related

• Same group: L2.01.1 Open input does not cue the range of capability · L2.01.2 Not knowing how to say it is the main barrier · L2.01.3 Differences in wording produce differences in results · L2.01.4 An empty box conveys no boundary; the first sentence is a guess · L2.01.5 Open input steers failure attribution toward “I said it badly” · L2.01.6 Synonymous phrasings yield different results, so users invent phrases to memorize · L2.01.8 Error messages for open input stay vague because the system does not know what the user meant to do
• Nearby: L1.02 Expressing Capability Boundaries · L2.02 Discoverability of What Can Be Said · L4.06 Permission Boundaries of Agents
• Search terms: non-enumerable capability · open-ended feature inventory · negative capability list