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.
☐
Business action ID assigned
☐
Approval scope linked
☐
Each hop identity recorded
☐
Receipt meanings distinguished
☐
Provider and local outcomes bridged
☐
Duplicates/late events handled
☐
Notification separate
☐
Unknowns owned before retry
0 of 8 marked
Key takeaways
- One business action needs one cross-system identity.
- Accepted is not settled, posted, or communicated.
- Reconcile before retrying or compensating.
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
- Provider succeeds after local timeout: query and reconcile instead of creating a new business action.
- Two local records reference one provider object: determine duplicate representation versus duplicate effect.
- Compensation succeeds externally but notification fails: close effects and communication separately.
Sources and references
Follow each source to check the underlying claim. Access checks and professional review are different steps.
1. Primary source · Stripe
Idempotent requestsAn idempotency key lets supported requests be retried without intentionally creating another operation. Provider scope and retention behavior differ.
Source checked 2026-09-18
Automated source-access check: 2026-09-18.
Continue the workflow
Recover from an uncertain integration outcomeWebhook replay reconciliation for property workflowsAI tool-schema version compatibility test packetExternal-provider outage handback from manual processingRevision history
2026-09-18
Initial Phase 5 operational article with distinct intent, original artifact, source limits, and AI-assisted technical review.