Workflow trajectory

Constructing a trajectory requires a way to connect events to the same case or task and order them appropriately. Timestamps, identifiers, action descriptions, and application state can contribute. Missing events, clock differences, retries, and work performed outside the recorded system should be documented.

For agent tasks, it can be important to distinguish what the operator knew at each step from information recorded later. Otherwise, a sequence may accidentally include answers that were unavailable during the original task.

Sequences can support questions about decisions, recovery, and outcomes that isolated records cannot answer. Whether they are useful for training or evaluation depends on coverage, labels, and rights. Sensitive information can occur throughout the trajectory, including screenshots and free text.

Fictional example: A return-handling trajectory links the initial request, inspection result, approval action, and refund confirmation. It also records a failed first attempt and the correction, rather than presenting only the successful final state.

Event order does not prove causation or reveal every reason for a decision. A trajectory may be incomplete or reflect a flawed process. A polished demonstration and a routine operational log need different interpretation.