Define identity and action state
This fictional action service accepts request DEMO-88 once. A confirmed receipt means one booking exists; a missing response means the assistant does not yet know the result. The worksheet specifies desired behaviour and does not claim that any API implements it.
| Supplied evidence | Question or input | Expected result |
|---|---|---|
| DEMO-88 has a confirmed success receipt | User sends “Book it” again. | Report the existing booking; create no second booking |
| DEMO-88 response was lost; state is unknown | Retry immediately? | Check DEMO-88 state first; do not assume the write failed |
| DEMO-88 was explicitly rejected; no write exists | User corrects the invalid time. | Follow the agreed retry/correction rule and record the corrected request |
Verify writes as well as replies
| Evidence | Why it is needed |
|---|---|
| Stable request reference | Connect retries to the same business request |
| Action log and resulting record count | Check whether a duplicate write occurred |
| State check after the lost response | Separate an unknown outcome from a known failure |
A polite “already handled” reply is not a pass if two records were created behind it. If the actual action system cannot expose request state, record that limitation and define a staff handoff; do not label uncertain completion as a failed action to justify another write.