Report partial failure structurally

Result contract

Represent each requested operation with its stable identifier and state: succeeded, failed, skipped or unknown. Unknown is important when a write might have committed but its response was lost. Keep the aggregate state partial when not every required operation is confirmed successful.

Example

{"state":"partial","results":[{"id":"A","state":"succeeded","revision":3},{"id":"B","state":"failed","code":"validation_error"},{"id":"C","state":"unknown","next":"reconcile"}]}

Recovery behavior

Do not replay A when repairing B. Correct B's input before retrying it. Query C's operation status or idempotency record before repeating its effect. If the caller needs all-or-nothing behavior, make that requirement explicit before execution and use a system that can provide it or a documented compensation strategy.

Acceptance and limits

Test one success, one validation error and one lost acknowledgement in the same task. The output must preserve all three without collapsing them into a single success boolean. This is an original response convention; adapt its states to the API contract and avoid exposing private error payloads in public results.