How should a data model represent the meaning of a handover?

A useful representation separates the enduring work item from the events that move it between teams. The work item can retain `work_id`, `current_owner_team`, `lifecycle_state` and `open_dependency_ids`. A transfer event can carry `transfer_id`, `work_id`, `sender_team`, `recipient_team`, `event_type` and `event_time`.

The event type should express what happened. A routing event records delivery to a queue; an acknowledgement records receipt; an acceptance event can change responsibility under the scoped workflow rules. Collapsing all three into a generic status update hides the distinction the model needs to learn.

A generated JSONL release could contain one event per line, with a separate work-item table for durable attributes. Training examples could reconstruct the work item's state at a selected event boundary and ask the model to explain the effect of the next event.

For a simulated environment, transition rules should specify which events alter ownership and which leave it unchanged. This provides an explicit connection between the language of a handover and its operational effect, rather than relying on a free-text note to encode both.