How should a technical catalogue explain the time model behind follow-up decisions?

A technical listing can explain lateness through three separate concepts: when an obligation was due, when information became visible to the system and when the agent is asked to decide. Combining these into one timestamp can create misleading tasks.

A generated record could contain `due_at`, `event_occurred_at`, `event_recorded_at` and `decision_as_of`, with `timezone` and `calendar_id` defining interpretation. An insurance administrator may receive confirmation after a request deadline even though the responding party completed the action before that deadline. The correct decision depends on what the administrator could know at the decision point.

MirrorFirm could package these fields in JSONL episodes with a schema that defines event time and visibility time separately. A downstream adapter can filter evidence by `event_recorded_at` before presenting the observation to an agent. The evaluator should use the episode's `decision_as_of`, not the host computer's clock.

For a reseller, this is a concrete technical differentiator: the product can represent late activity and late knowledge independently. The catalogue should state whether both are modelled, because customers testing agents against delayed updates need that distinction to interpret results.