What tables and tool actions does a simulated booking environment expose?

A simulated booking environment can be described by a small set of tables and a fixed list of tool actions.

**State tables** (Parquet or JSONL):

- `approval`: `approval_id`, `application_id`, `product_type`, `limit_amount`, `rate_type`, `rate_percent`, `term_months`, `approved_by_role` - `condition`: `condition_id`, `approval_id`, `description`, `status`, `due_before` - `facility`: `facility_id`, `approval_id`, `status`, `limit_amount`, `rate_percent`, `repayment_frequency` - `security_link`: `facility_id`, `security_id`, `lien_rank`, `status` - `booking_event`: `event_id`, `facility_id`, `actor_role`, `action`, `from_status`, `to_status`, `at`

**Tool actions** (JSON arguments, JSON results): `get_approval`, `get_facility_draft`, `compare_terms`, `link_security`, `update_field`, `raise_hold`, `clear_hold`, `raise_query`, `set_status`, `generate_schedule`.

Each action should return a structured result and an error code for refused calls, such as a status change blocked by an open condition. Refusals are useful evaluation signals.

Reset: a `scenario_seed` identifier maps to a snapshot of all tables, so one call restores the starting state. Ask for the snapshot format and whether resets are deterministic before you describe the environment to your customers.