Status: accepted, 2026-08-18 (owner nod on two defaults proposed after the class-model review)

Context#

The class-model review (../evidence/20260818-class-model-review.md #2, #9) found two things: the charter said a module is one capability while the vocabulary doc had widened it to one-or-more payloads, and the word "payload" meant both the class of code and the per-item input field on the wire ({item_id, payload} in versable-runner, payload.json in its bucket).

Decision#

A module is one capability by default, its variants and its judges included; co-hosting a second capability in one deployment is the stated exception in ../canon/14-graceful-degradation.md, not the default. The per-item input field on the wire is input, so "payload" means only the capability code; versable-runner's payload.json and {item_id, payload} are a lapse to rename on its upgrade (../patterns/03-upgrading-services-api.md).

Rejected alternatives#

• Widen the module to any number of payloads: makes adr/001's "many module deployments" indistinguishable from App V5's one runner with everything registered.
• Rename the class instead of the wire field: every candidate ("capability code", "method") collides worse with the manifest's capability id or App V5's method registry.

Consequences#

• contracts/module-surface.md, contracts/manifest.md, canon/03, canon/11, patterns/01, and v6/README.md say input.
• The extractor and versable-runner instance docs carry the rename as a parity-ledger row when upgraded.