How does approval authority map onto environment state and tool actions?

Authority logic fits an environment as a small set of linked tables plus a few tool actions that read and change them.

**State entities**

- `person` and `role`, linked through `role_assignment` with `start_date` and `end_date`. - `authority_rule` with `role_id`, `action_type`, `amount_max`, `risk_class_max`, `period_cap` and `effective_from`. - `delegation` with `from_person_id`, `to_person_id`, `scope`, `valid_from` and `valid_to`. - `request` with `request_id`, `requester_id`, `amount`, `risk_class`, `status` and `current_assignee_id`. - `decision_log` with `request_id`, `actor_id`, `action`, `timestamp` and `rule_id_applied`.

**Tool actions**

- `get_request(request_id)` and `get_authority(person_id, at_time)` return state. - `approve(request_id, actor_id, comment)`, `reject(...)`, `escalate(request_id, to_person_id, reason)` and `request_info(...)` change it.

Design the environment so `approve` does not validate authority itself. The tool writes the decision and lets a separate policy checker, run after the step, label it valid or invalid. This keeps the temptation to take invalid actions realistic and lets you score the agent on what it chose.

Keep a simulated clock as state, because delegation windows and period caps depend on it. Expose it through a `now()` tool or a field on each observation.

All records are generated, so the schema can be adapted to your engine in a pilot; ask for field names and key relationships to match what your environment already uses.