Choose against the task constraints
A fictional venue accepts room enquiries. One room has fixed capacity and automatic eligibility checks; another needs a staff-approved setup plan before the date can be committed. The example considers interface state only, not payment or venue safety certification.
| Condition | Request followed by review | Instant confirmation |
|---|---|---|
| Required decision remains open | Display received and pending review | Cannot truthfully confirm until resolved |
| All stated prerequisites pass | Adds a manual queue if no review is needed | Can confirm after authoritative capacity check |
| No response from the system | Do not imply staff received an unsent request | Do not turn uncertainty into confirmed capacity |
Route B-room choices into a request state until setup approval arrives. A-room bookings can use immediate confirmation only after the actual acceptance checks succeed. Keep the button label, resulting status and notification consistent.
A receipt is not an approval
| Request | Evidence | Honest next state |
|---|---|---|
| A-7 | Eligibility and capacity accepted | Confirmed |
| B-9 | Received; setup unapproved | Pending setup review |
| B-10 | Submission outcome unknown | Check receipt before retry |
Can B-9 display confirmed because the request has an ID?
Show the worked answer
No. Identity proves a request record exists, not that setup is approved. Keep it pending until the required decision is recorded.
Check the chosen interaction
- Pending and confirmed states have distinct text.
- A response timeout does not create a second request automatically.
- A confirmation names the accepted date, room and booking identity.