0033: Separate Reachability, Affordance, And Acceptance

Status: Accepted

Date: 2026-07-21

Context

STAGE already separates automated input reachability from human acceptance. Lanternworks exposed a missing boundary between them. A deterministic virtual Gamepad rehearsal completed the First Light economy through the real input adapter, Commands, simulation, and views. The ordinary player surface still showed no visible build, route, remove, save, or load controls. Mouse users could select Cells but could not operate the complete loop without learning hidden keyboard mappings from documentation.

The rehearsal was valid evidence for the claim it actually exercised. The mistake was allowing that result to imply that the action set was presented to an ordinary player. A production input path can exist while its affordance is absent, obscure, disabled in the current mode, or available only through external instructions. Conversely, the presence of a labeled control does not prove that its wiring works or that a person understands and enjoys using it.

This failure was found by inspecting the ordinary playable surface before building more review infrastructure. The product-native Visual Almanac had other legitimate consumers, but it did not answer whether the main game surface exposed the core command set.

Decision

For player-operated interaction claims, record three distinct boundaries:

1. Mechanical reachability: production mapping, focus or targeting, adapters, domain action, and resulting state form an executable path.
2. Affordance presentation: the ordinary production surface exposes the relevant action and current mode through the intended controls, prompt, tutorial, convention, or other product-owned presentation.
3. Human acceptance: a person notices and understands the action and judges its responsiveness, accessibility, comfort, pacing, and value.

Use automation to prove mechanical reachability where practical. Inspect the ordinary production surface to prove only the objective presentation claim: that the intended affordance is present, visible in the relevant state, and bound to the same production path. Reserve comprehension, usability, and feel for human evidence.

Do not require every action to have an on-screen button. Keyboard shortcuts, controller conventions, contextual prompts, tutorials, diegetic cues, and deliberately hidden mechanics can all be valid product decisions. State which presentation policy the claim relies on. If discoverability is intentionally out of scope, narrow the claim rather than silently treating hidden knowledge as player-facing operation.

Inspect the ordinary player or author surface before proposing a custom gallery, rehearsal host, or detached evidence system. Add persistent review infrastructure only when that surface cannot answer a recurring, named review question.

Consequences

• A virtual input rehearsal no longer implies that an ordinary player can find or operate the action set.
• A visible button no longer implies that its production input and domain path work.
• Consumer-complete verification for a player-operability claim includes both the action path and its intended production presentation.
• Human understanding remains a separate acceptance result rather than an agent inference from layout or labels.
• Intentional hidden controls remain possible, but their evidence and claim must say so explicitly.
• Direct inspection of the ordinary product surface is preferred over new verification machinery when it can reveal the omission.

Evidence Boundary

The Lanternworks Command Deck correction is same-director Unity dogfood. It supports the distinction and demonstrates one repair: expose the complete command set in the existing HUD while routing every control through the shared input driver. It does not prove that the revised controls are understandable, comfortable, accessible, or enjoyable; those judgments remain pending human play review.