Reliability without guesswork.

A network timeout does not tell you whether work happened. Treat unknown outcomes as a first-class state and reconcile before retrying.

Preview note. The patterns below describe the intended enterprise contract. They do not advertise a public endpoint or guarantee production availability.

Recommended outcome model

Outcome	Client action
Accepted	Persist the returned request identity and wait for the next state.
Rejected	Do not retry unchanged input; fix the reported validation issue.
Rate limited	Back off according to the response guidance and preserve the same operation identity.
Unknown	Reconcile by request identity before issuing a new operation.

Idempotency and replay

Generate one stable idempotency key per business operation, not per network attempt. Store the key with your source record and reuse it after timeouts. A changed payload with an existing key should be treated as a conflict and investigated, not silently overwritten.

business_operation_id → idempotency_key → request_id → outcome

Evidence and stale revisions

Validation and correction decisions should reference the revision they evaluated. If a revision is stale, stop and re-read the canonical history before applying a correction. Preserve the evidence trail so an operator can explain what changed and why.

See held-order correction for the synthetic lifecycle and API guides for request semantics.