How can a simulated environment expose different information to different teams?

A generated environment can maintain an underlying state while exposing only the records and fields available to the acting role. In healthcare administration, a bookings team might see referral readiness and appointment constraints, while a separate administrative review team sees supporting eligibility documentation.

A schema can express this through `record_id`, `record_type`, `linked_case_id`, `visibility_scope` and `field_access_rules`. Role definitions can specify readable fields and permitted actions. The environment should apply those rules when constructing tool responses, rather than merely placing a warning in the task prompt.

Tools such as `get_case`, `request_review` and `transfer_to_queue` can return role-appropriate results. A request for a restricted field can produce an explicit access response and a permitted route for obtaining the operational conclusion needed to proceed.

MirrorFirm could scope these views as generated environment state. The deliverable should distinguish the evaluator's full-state access from the agent's restricted view. Otherwise, a buyer may unintentionally train on information that the task's assigned role should never have received, making the apparent coordination problem substantially easier than intended.