making-effects-reliablelisted

# Making Effects Reliable ## Overview A pure core is safe to run twice. An effect is not: a charge that runs twice is two charges, and a call that times out may have succeeded. Once a workflow reaches a second system, the failure modes stop being about correctness of logic and start being about delivery, duplication, and partial completion. The rules below all follow from one idea: keep the decision pure and idempotent-by-nature, and make each effect separately identifiable, so that repeating it is safe and losing it is detectable. ## When to use - A workflow calls a payment provider, a queue, or another service - An operation must not happen twice, and retries exist - A timeout leaves you unsure whether the effect happened - Events must reach a consumer, and the database write must also happen - Deciding where retries, timeouts, and compensation live - A process spans minutes or days and can fail halfway Not for: in-process concurrency, which is [managing-state-immutably](../managing-state-immutably/SKILL.md); or choosing transaction boundaries, which is [enforcing-consistency-boundaries](../enforcing-consistency-boundaries/SKILL.md). ## Core rules 1. **Give every command an identity.** A client-supplied key, carried through the workflow, is what makes de-duplication possible at all. 2. **Make the effect idempotent, not the decision.** The pure core is already safe to repeat; the write, the charge, and the send are not. Idempotency belongs in the adapter. 3.