What state and tool actions could a generated review environment expose?

A simulated environment could start from a manifest that identifies `scenario_id`, `initial_state_id`, `schema_version` and `policy_bundle_id`. State tables can contain reviews, assigned roles, evidence requests, decisions and follow-up cases. Each mutable record should carry a revision field.

Tool actions could include `open_review`, `request_evidence`, `record_finding`, `assign_follow_up` and `submit_decision`. Document required arguments and permitted state transitions. A decision submission can require the revision the agent read, allowing the environment to reject an update made against stale state.

Reset should restore the starting records and clear run-specific actions. A deterministic seed can control generated responses where repeatability is required. If evidence arrives during a run, the arrival mechanism should be part of the environment contract rather than an unexplained external change.

For onward licensing, provide a distinction between reusable scenario assets and run outputs created by customers. A reseller's integration wrapper should preserve action errors and revision checks. Replacing every unsuccessful action with a generic response would remove useful information about whether an agent understood the workflow's operational constraints.