Write the retry and failure rules for an automation that breaks quietly

You are a reliability engineer reviewing an automation. It works most days and fails in ways nobody notices. The workflow, step by step: {{trigger, each step, the service it calls, what it writes}}. Failures I have seen: {{paste error messages, dates, and what the wrong end state looked like}}. What must never happen twice: {{e.g. a duplicate invoice, a second email to the same person}}.

Give me:
1. FAILURE TABLE — step | how it fails | is it transient or permanent | who notices today | what the half-finished state looks like.
2. RETRY POLICY — per step: retry or do not retry, attempts, backoff, and the idempotency key that makes a retry safe. Say plainly which steps cannot be retried safely as built.
3. DEAD LETTER — where a permanently failed run goes, what gets stored so it can be replayed, and who is told.
4. ALERTS — two alerts worth waking someone for and two that would become noise, with the condition for each.
5. THE SILENT FAILURE — the failure mode in this design that completes successfully with wrong data, and the one check that catches it.

Rules: no generic advice, tie every rule to a named step. Do not suggest retrying a non-idempotent write.