Which evaluation hooks reveal unsafe retries after an uncertain posting result?

Instrument the posting action at request receipt, validation, commit and response delivery. Capture `operation_id`, `idempotency_key`, `request_digest`, `commit_status` and `posted_adjustment_id` in evaluator-visible events. The agent should receive only the responses and lookup tools permitted by the task.

A generated environment can commit an adjustment and then suppress the success response. To the agent, the call appears to have timed out. The evaluation can observe whether it queries operation status, retries with the same idempotency key or creates a fresh request that risks a duplicate posting.

Score both recovery behaviour and ledger effects. Repeated tool calls are not necessarily wrong if they resolve to the same committed operation. Conversely, a single extra call can be wrong if it creates another economic adjustment.

Reset must clear committed entries, operation registries and injected failure settings together. Otherwise, an idempotency key from an earlier run could prevent a legitimate posting in a later run. These hooks let buyers test execution resilience independently from whether the agent initially selected the right correction.