01 / State map
A retry is not permission to send twice.
The worker received the same request twice. The first attempt has no durable receipt, so the safe path is to deduplicate and inspect the provider response before releasing another write.
| Field | Value | Reading |
|---|---|---|
| attempts | 2 | observed |
| idempotency_key | missing | boundary |
| provider_receipt | unknown | withheld |
02 / Failure ledger
The evidence gap is the finding.
Duplicate write riskHold the action until one provider outcome is known.
Missing idempotency keyRetry identity cannot be proved from the fixture.
Unknown provider receiptSuccess must not be claimed from worker state alone.
03 / Repair sequence
Smallest safe hardening path.
- 01
Derive a deterministic idempotency key from the request identity and target.
- 02
Persist and inspect the provider receipt before releasing another write.
- 03
Retry only with the explicit key and record the resulting state transition.
- 04
Return an acceptance receipt that separates worker completion from provider success.
04 / Acceptance receipt
What the next phase must prove.
- The duplicate input produces no second provider action.
- The provider receipt is durable and linked to the request key.
- A replay is explicit, observable, and safe to stop.
- The final report names what is proved, withheld, and still unknown.
Truth boundary: this is RomeoApps-owned synthetic demonstration work, not a customer incident, production result, uptime claim, or client case study.