Provider reconciliation matrix
Provider reconciliation is the part of Once that asks an external system what actually happened after an ambiguous outcome. This page makes the current evidence boundary explicit instead of implying support for providers that have not been publicly demonstrated.
| Provider / environment | Execution path | Authoritative reconciliation | Public evidence | Status |
|---|---|---|---|---|
| Reference / simulated provider ledger | Used by hostile-retry labs | Yes, by the test provider contract | LangGraph and CrewAI hostile-retry labs | Reproducible reference evidence |
| Agno hostile-retry test provider | Released SDK receives repeated invocations | Bound to the lab's controlled provider/effect model | Control can produce 3 effects; Once path commits 1 | Reproducible framework evidence |
| Hosted / synthetic Once runtime test | Cloud-hosted runtime test path | Demonstrated against the synthetic provider contract | Two attempts, one provider execution / external effect, durable replay | Demonstrated hosted evidence |
| Stripe live production API | Not claimed here | No public production reconciliation adapter is claimed on this page | Stripe sandbox may be used for product/billing demos, but that is not the same as a proven refund/payment reconciliation adapter | Do not infer support |
| Controlled booking lifecycle fixture | Published SDK 0.1.25 wrapTool; create/modify/cancel with same-machine SQLite | Exact unique historical operation receipt from the mock provider journal; delayed, missing or conflicting truth stays UNKNOWN | Reproduce the lifecycle reference; Windows/Ubuntu clean-consumer evidence | Local mock contract only; not a production provider adapter |
| Booking / reservation providers | Not provider-specific by default | Requires an integration that can establish provider truth or an equivalent downstream guarantee | No named production provider adapter claimed here | Adapter / integration required |
| Email / messaging providers | Not provider-specific by default | Requires authoritative status semantics suitable for the operation | No named production provider adapter claimed here | Adapter / integration required |
| Arbitrary third-party APIs | No universal automatic guarantee | Depends on provider truth, provider-native idempotency, or another trustworthy downstream primitive | No universal exactly-once claim | Evaluate individually |
ADK parallel-replay evidence uses another controlled provider journal. Neither fixture establishes named payment or booking provider support.
What counts as authoritative truth?
An empty local ledger, a timeout, a missing acknowledgement, or a non-authoritative 404 is not enough by itself to establish ABSENT. Once is strongest where the external system can answer whether the specific logical operation already committed, using a stable identifier or an equivalent authoritative lookup.
Decision model
CONFIRMED — replay or suppress. ABSENT — recovery depends on the specific integration. Conservative local protection does not redispatch an ambiguous write after an absence observation. UNKNOWN — fail closed rather than guess, then reconcile later when truth becomes available.
Integration principle
Once is intended to complement provider-native idempotency, database constraints, durable workflow engines, and other downstream safety primitives. It should not replace a stronger guarantee already offered by the provider.