How should complaint histories represent events that arrive out of order?

A complaint history benefits from separate fields for `occurred_at`, `recorded_at` and `visible_from`. The first records when an action happened, the second when a system captured it, and the third when the acting role could access it. These times need not match.

A call note may be entered after a complaint has already moved to investigation. If the note confirms that an acknowledgement was delivered earlier, it changes the known history without making that evidence available retrospectively to the model.

A generated event stream could link each event through `case_id`, `event_id` and `source_record_id`. An observation builder can filter on `visible_from` before producing each task input. JSONL suits ordered event replay; a Parquet export can support analysis across event types and visibility delays.

An evaluation hook can record the evidence visible at the moment of each action. This allows reviewers to distinguish a poor decision from a reasonable decision made before a delayed record arrived. It also supports training on revision: the model should update its assessment when newly visible evidence changes what can be established.