Which records and tool contracts can drive a generated handover environment?

A generated release can provide initial state as Parquet tables and action events as JSONL. The initial tables might contain `work_items`, `handover_packages` and `team_assignments`, linked through stable identifiers. Events describe changes rather than duplicating the full current record.

A handover package schema could include `handover_id`, `work_item_id`, `sender_team_id`, `recipient_team_id`, `package_version` and `status`. A transfer action can accept `expected_version` and `idempotency_key` alongside the package identifier.

Version checking matters when another role updates the package after the agent reads it. The action should return a defined conflict result rather than transferring a superseded package. An idempotency key lets the environment recognise a retry after an interrupted response and avoid creating duplicate transfers.

Specify whether validation, state mutation and event emission occur atomically. If package ownership changes but the event is missing, replay and evaluation may disagree about what happened.

For reset, reload the initial snapshot and clear the episode's event stream, retry keys and version counters. A transition hook can emit the action identifier, previous version, resulting version and validation outcome, giving builders a consistent basis for replay and debugging.