How should an evaluation represent the lifecycle of a handover?

A generated environment could represent each transfer as an event sequence rather than a mutable assignment field. Useful fields include `transfer_id`, `case_id`, `event_id`, `event_type`, `actor_role`, `from_team`, `to_team` and `occurred_at`. A `caused_by_event_id` link can connect a receipt or rejection to the dispatch that prompted it.

Define permitted transitions in a separate schema. A transfer might move through prepared, dispatched, received and accepted, with rejected and withdrawn as alternative outcomes. Keep the transfer lifecycle separate from the case lifecycle: accepting responsibility does not resolve the underlying work.

Tool actions could include `prepare_transfer`, `dispatch_transfer`, `accept_transfer` and `reject_transfer`. Each action should declare its preconditions and return the resulting event identifier. Invalid transitions should produce structured errors that the evaluator can inspect.

An evaluation hook can compare the emitted event sequence with the permitted transition graph. This catches agents that claim acceptance without a receiving action, accept a withdrawn transfer or confuse case closure with transfer completion. JSONL can preserve the ordered events for replay and inspection.