Failure injection
Amana treats the outcome as unknown, reconciles provider state, and refuses to create a second order until truth is known.
An unknown create-order outcome must be reconciled before another provider order can be created.Executed evidence trace
Visualization of an executed deterministic Testcontainers proof case. No live provider call is performed.
Immutable proposal and bound approval enter the Execution Gate.
One execution owns a stable idempotency identity and receipt.
The inert provider receives exactly one create-order command.
The provider creates the order, then a TIMEOUT hides the response.
The creation attempt is persisted as UNCERTAIN—never guessed failed or successful.
The uncertain attempt prevents another provider create call.
Amana queries the inert provider by the stable execution receipt.
The original provider order is validated and bound to the execution.
Execution advances to PAYMENT_PENDING; payment truth remains uncertain.
One reservation. One create call. One provider order.
Measured fixture evidence
This is a replay of a generated artifact from the real execution and payment services running against PostgreSQL 17 with an in-process provider adapter.
Final payment state: PAYMENT_UNCERTAIN. Recovered order existence is not captured-payment evidence, so this proof does not claim PAYMENT_CONFIRMED.
PaymentControlService.initiate persists the attempt. PaymentControlService.reconcile resolves the stable receipt, while PaymentRepository enforces one provider-order binding per execution.