You also need to say what happens when the reservation is already confirmed. Checking the clock first could accidentally expire a reservation that completed earlier.
Turn the wording into a small decision contract
This authored teaching scenario has states PENDING, CONFIRMED and EXPIRED. A request carries one trusted arrival timestamp in the same time basis as the stored deadline. Network ordering, clock synchronization and concurrent database transactions are outside this small decision function and must be handled by the real system.
The owner has chosen these rules:
- CONFIRMED and EXPIRED are final states for this function. Return the existing state unchanged.
- For PENDING, an arrival later than the deadline changes the state to EXPIRED.
- For PENDING at or before the deadline, an accepted payment changes the state to CONFIRMED.
- A declined payment before or at the deadline leaves the reservation PENDING.
“Accepted payment” is a supplied decision here, not an instruction to charge a card. Unknown payment results require a separate rule; treating unknown as declined would invent policy.
Put final-state handling before time handling
DECIDE(currentState, arrivalTime, deadline, paymentAccepted)
REQUIRE currentState is PENDING, CONFIRMED or EXPIRED
REQUIRE comparable arrivalTime and deadline
REQUIRE paymentAccepted is a known Boolean
IF currentState is CONFIRMED OR currentState is EXPIRED
RETURN currentState
IF arrivalTime > deadline
RETURN EXPIRED
IF paymentAccepted
RETURN CONFIRMED
RETURN PENDING
This function returns a proposed state. It does not write a database, issue a refund, release inventory or send a notification. Those effects need explicit ownership and transaction rules in a production design.
The order expresses precedence: final state wins first; lateness wins for pending requests; payment decides only a still-eligible pending request. Using greater-than-or-equal for lateness would contradict the inclusive deadline.
Walk the boundary without a programming language
Assume the deadline is 12:00:00 on the same stated day and time basis:
| Starting state | Arrival | Payment accepted | Returned state |
|---|---|---|---|
| PENDING | 11:59:59 | yes | CONFIRMED |
| PENDING | 12:00:00 | yes | CONFIRMED |
| PENDING | 12:00:01 | yes | EXPIRED |
| CONFIRMED | 12:00:01 | yes | CONFIRMED |
| PENDING | 12:00:00 | no | PENDING |
| EXPIRED | 11:59:59 | yes | EXPIRED |
For the fourth row, execution stops at the first IF. For the exact-deadline rows, the lateness comparison is false, so payment decides. Explain those paths aloud; a table of correct answers can hide pseudocode whose branch order is wrong.
Ask ChatGPT to expose missing policy
Help turn this reservation rule into language-neutral pseudocode.
States, final-state behavior and allowed inputs: [PASTE]
Chosen timestamp source/time basis and inclusive deadline: [PASTE]
Known payment outcome representation: [PASTE]
Boundary examples and expected states: [PASTE]
List unresolved policy questions before filling gaps. Write one
decision function returning only the next state, with ordered branches
and explicit comparisons. Walk every example through the branches.
Keep persistence, charging, notifications and concurrency out of this
function; list required integration decisions separately.
Do not invent a refund rule or silently treat an unknown outcome as no.
OpenAI's prompting guidance, checked October 24, 2026, supports specifying the result and constraints. The particular states and rules above belong to this authored exercise, not to a product behavior described by OpenAI.
Approve the traces before translating the branches
Ask the rule owner to approve the exact-deadline and already-confirmed outcomes. Then implement the pseudocode in the intended language and turn the approved rows into assertions using that project's test framework. Python's unittest reference is one example of an assertion-based runner, not a required language choice.
The test-case guide covers selecting checks from requirements. This exercise supplies the decision order those checks should exercise. Keep the approved pseudocode, implementation and boundary traces together so later changes reveal whether the business rule itself changed.