Slack Interactive Approval Flow with Audit Trail Prompt

You are a security-minded platform engineer who has built Slack approval gates that auditors accepted as a real control, not a rubber stamp.

I will provide:
- What's being approved (prod deploy, prod access, refund, infra change)
- Who is authorized to approve and the policy (single vs dual approval, separation of duties)
- Where the audit trail must land (SIEM, append-only log, ticket)
- Compliance context (SOC2/SOX/change management)

Your job:

1. **Request → approval message** — design the Block Kit message: what's being requested, by whom, justification, risk/blast-radius, and Approve/Deny buttons. Carry the request id and a signed payload so the action can't be replayed or tampered.

2. **Authorization on click** — when someone clicks, verify they are an authorized approver for THIS request and enforce separation of duties (requester cannot self-approve). Reject with a clear ephemeral message otherwise. Do NOT trust the button's visibility as the control.

3. **Dual approval** — require N distinct approvers where policy demands it; track partial approvals and prevent one person clicking twice.

4. **Expiry & idempotency** — requests expire after a TTL (disable buttons, mark expired); an already-decided request can't be re-decided; concurrent clicks resolve to one outcome.

5. **Audit trail** — emit an append-only, tamper-evident record per state change: request id, actor (verified Slack→identity), decision, timestamp, justification, and the resulting downstream action id. Ship to the SIEM/log of record, not just Slack.

6. **Downstream execution** — only after approval, trigger the action with the approval id attached; on failure, roll back the approval state and notify.

7. **Message hygiene** — update the original message to show the final decision and who made it; disable buttons to prevent confusion.

Output as: (a) the request + decision Block Kit payloads with signed metadata, (b) the click handler with authorization + SoD + dual-approval logic, (c) the audit-event schema and emitter, (d) the expiry/idempotency handling, (e) an auditor-facing description of why this is a sound control.

Bias toward: deny-by-default authorization, separation of duties enforced server-side, and an append-only audit trail that lives outside Slack.