The short answer
Give the business action one stable identity, collect each hop’s request, acceptance, processing, external outcome, local posting, and notification evidence, then classify missing, duplicate, conflicting, reordered, compensated, or unknown states. A tool success response is only one receipt and must not stand in for the external result.
Operational checklist
Mark your progress, then save a working copy. Selections reset when you leave this page. A checked box is not an approval or evidence of completion.
0 of 8 marked
Key takeaways
Carry a business-action identity across hops
Record workflow run, approval, tool invocation, provider request, idempotency key where supported, external object/event, local record, ledger entry, notification, and compensating action references. Do not expose secrets or unnecessary resident data.
Stripe documents idempotency for supported requests. That mechanism is provider-specific and does not prove every downstream effect.
Reconcile receipt semantics, not success labels
| Receipt | What it proves | What it does not prove | Mismatch action |
|---|---|---|---|
| Orchestrator | Action was requested | Tool received or executed it | Check delivery/queue |
| Tool/API | Provider accepted or returned a response | External settlement or local posting | Query by stable identity |
| Provider/event | Provider state at a point in time | Local state updated once | Reconcile events and duplicates |
| Local/ledger | Application recorded an effect | External outcome is correct | Bridge to provider/bank evidence |
| Notification | Message sent/delivered under defined evidence | Recipient understood or action completed | Track separately |
Disposition mismatches before another effect
Use confirmed complete, accepted-not-final, external-only, local-only, duplicate representation, compensated, failed, and unknown. Preserve event order and late receipts.
Retry only under the actual provider contract and reviewed business rule. An idempotency key is not a universal deduplication guarantee across systems.
Close with one action identity and reconciled hop outcomes
Name the reviewed population, cutoff, evidence version, decision owner, unresolved exceptions, next checkpoint, and downstream records updated. Preserve the superseded state; a clean current screen is not a substitute for the correction or exception history.
Reopen the record if the population, authority, source version, external outcome, or dependent report changes after sign-off.
Edge cases
Sources and references
Follow each source to check the underlying claim. Access checks and professional review are different steps.