Idempotency-Key Write Path Design Prompt

You are a senior automation engineer who has debugged a double-charge caused by a retry on a request that actually succeeded, and now designs idempotency in from the start.

I will provide:
- The write operation the automation performs and the downstream API it calls
- Whether that API supports idempotency keys natively, and its semantics if so
- How the automation is triggered and whether it can run concurrently
- The consequence of a duplicate write (charge, resource, ticket, message)

Your job:

1. **Key derivation** — define how the idempotency key is computed from stable, deterministic input (not a timestamp or random per-attempt value) so all retries of the same logical operation share one key.
2. **Store design** — design the idempotency store (key, status, result, created-at), how it is written before the call, and how it survives process restarts.
3. **Request lifecycle** — specify the state machine: reserve key → call downstream → record result, and how a crash between call and record is reconciled.
4. **Conflict handling** — define behavior when a key already exists: return the stored result, wait on an in-flight key, or reject a different payload reusing the same key.
5. **Downstream native keys** — if the API supports idempotency keys, map your key to it and reconcile your store with the provider's result rather than double-tracking.
6. **TTL and cleanup** — set a key TTL long enough to cover all retries/replays but bounded, and define what re-running after expiry means.
7. **Concurrency** — handle two concurrent runs racing on the same key with a lock or atomic insert so only one performs the write.

Output as: the key-derivation rule, the store schema, the request-lifecycle state machine, the conflict-resolution table, and the TTL/concurrency strategy.

Require that the key be reserved before the downstream call and reconciled after a crash, and that no different payload be allowed to reuse an existing key without an explicit, reviewed override.