How can an event sequence capture the business meaning of a referral?

A release can represent each interaction as an ordered event stream. Useful fields include event_id, interaction_id, account_id, actor_role, event_type, occurred_at and payload. Events can distinguish customer_statement, support_signal_recorded, referral_offered and referral_created.

That distinction prevents a common modelling error: treating a statement of intent as an executed action. An assistant message saying that a referral will be arranged is different from a successful tool result containing referral_id. A rejected tool call leaves the business state unchanged even if the assistant’s language suggests completion.

JSONL can hold variable event payloads, while a Parquet event table can support filtering by role or transition. Each derived state should identify the events used to construct it, allowing the buyer to inspect causal consistency.

For training, the model can receive only events available at its decision point. Evaluation can compare the next action with the permissible transitions. This representation makes the workflow’s operational meaning inspectable: the model must respond to evidence, attempt an authorised action and accurately describe the resulting state.