How should an evaluation represent when an event happened and when it became visible?

A late-payment evaluation can become misleading if every timestamp is treated as equivalent. A payment may occur before a follow-up decision but enter the accounting system afterwards. The agent's available evidence depends on arrival time, while the business interpretation may depend on event time.

A generated event schema could include `event_id`, `case_id`, `occurred_at`, `recorded_at`, `visible_from`, `timezone` and `event_type`. Link each event to the affected obligation through `obligation_id`. Preserve the original timestamps when producing JSONL events or a Parquet event table.

The environment clock should determine which events a retrieval tool returns. An evaluation hook can capture the visible record set at the moment the agent decides to contact, defer or escalate. This supports a defensible distinction between overlooking an available payment and acting before its arrival.

MirrorFirm could also generate backdated corrections and events with uncertain occurrence times. Buyers should specify whether agents may revise earlier decisions when new evidence arrives. Resetting an episode should restore both the event sequence and its visibility schedule, so repeated runs face the same information boundary rather than merely the same final database.