Why should an evaluation expose complaint events as well as current status?

A current status field compresses a sequence of business actions into a label. If CASE-0724 is marked escalated, an evaluator still needs to know who requested the escalation, which role received it and whether the receiving queue accepted responsibility.

A generated environment could expose a case snapshot alongside append-only events. Useful event fields include `event_id`, `case_id`, `event_type`, `actor_role`, `occurred_at`, `effective_at` and `related_record_id`. Separating occurrence time from effective time helps represent a late entry describing an earlier action without silently rewriting the history.

Tool actions such as `record_acknowledgement`, `request_investigation` and `submit_escalation` could create events with defined state effects. An evaluation hook can compare the final snapshot with the events that justify it. A status change without the required supporting action becomes detectable.

This representation also supports questions about sequence: did escalation happen before closure, and did acknowledgement occur before the agent claimed it had been sent? MirrorFirm could generate both valid histories and deliberately inconsistent ones, with the inconsistency documented in evaluator-only material.