# Lesson 5 practice: What should the user see after a timeout?

[中文](README.md)

For each request, explain what is known, what the user should see, and what they can do next. Open [events.csv](events.csv), group by `scenario_id`, and read each group in `event_order`. The eight rows describe five independent synthetic scenarios, not eight real incidents, original Beichen logs, or output from the course lab. They cover **recommendations and saving drafts only**. They do not authorize purchasing, equipment shutdowns, or device operations.

## Fields

| Field | Meaning |
| --- | --- |
| `event_id` / `scenario_id` | Event ID / independent scenario ID |
| `event_order` / `event_type` | Order within the scenario / event type |
| `request_id` / `idempotency_key` | Original request ID / idempotency key; preserve both for reconciliation |
| `record_id` | Draft ID returned by an authoritative lookup; a blank does not prove that no draft exists |
| `outcome` | `pending`, `unknown`, `draft_exists`, or `not_created` |
| `inputs_valid` | Whether the inputs remain valid |
| `authorization_valid` | Whether the current authorization remains valid |
| `api_retry_allowed` | Whether the API contract permits a retry |

The last three fields use `true` or `false`. A blank means the row provides no evidence, not `false` or an assumed pass. In this exercise, `authoritative_prewrite_rejection` explicitly confirms rejection before any record was created. An ordinary error or timeout gives no such guarantee.

## Walk through the requests

1. Stop at T02 before reading later rows. Write a message such as: “We did not receive the save result. The draft status is unknown. Check the original request before saving again.” Include the request ID, a lookup path, and a way to get human help.
2. Read T03. The authoritative system has draft `D-18`. Update the message to “Draft saved; application not submitted.” Offer a way to view the draft and continue through the existing approval process. Do not create another draft.
3. For the other four scenarios, check confirmed non-creation, valid inputs, valid authorization, and permission to retry under the API contract. Only `confirmed_not_created` provides evidence for all four. A retry may be considered under that contract; it is not automatically required and does not authorize a new action.
4. Give each blocked case an appropriate next step: correct and recheck inputs, contact someone with the required authority, or use the lookup or handoff process specified by the API. Avoid a single retry button for every outcome.
5. Add a case where lookup is unavailable. Keep the status unknown, pause duplicate actions, and escalate. Qualified personnel continue any equipment work through established professional procedures; the assistant does not issue device instructions.

## Check your reasoning

At T02, only the timeout is known. T03 establishes that a draft exists. T05 supports considering a constrained retry; T06–T08 each lack one required condition. An idempotency key in a CSV does not establish that a real API deduplicates requests, rejects changed parameters, or reconciles across systems. Those behaviors require documentation and tests.

These rows let you check whether your messages and next steps are consistent. They do not demonstrate production reliability. Distinguish a proposed response from tested behavior. A peer can read your messages and explain the next step; when studying alone, mark usability and system behavior as awaiting validation rather than inventing feedback.

Take your state table and one untested assumption into the Lesson 6 practice.