How can evaluation hooks detect duplicate or stale routing actions?

A routing action contract can accept request_id, destination_id, expected_state_version and idempotency_key. The environment can reject an action when its expected version differs from the current request version. It can also return the original result when the same idempotency key is retried.

An evaluation task could simulate a lost action response. The agent must recover without creating a second transfer. A separate task can insert a concurrent owner change between inspection and assignment, requiring the agent to refresh its view before acting again.

Useful hooks include action_attempted, stale_version_rejected, duplicate_action_suppressed and assignment_committed. An evaluator can inspect these events alongside the final destination, distinguishing a clean recovery from repeated side effects that happen to end in the right place.

For resale, keep the retry behaviour documented and include a reset seed that restores both request state and the action receipt ledger. Otherwise, customers may receive inconsistent results because an earlier run's idempotency history remains active. MirrorFirm could scope these failure conditions as part of an environment pack.