Which upstream and downstream systems must an evaluation harness model around booking?

A booking task is only realistic if the agent can see what a real analyst sees and the harness can see what happens next. A minimal model has five parts.

- **Approval source.** Records such as `approval_id`, `applicant_id`, approved limit, product code, pricing tier, authority level and a `conditions[]` array with `condition_id`, text and status. - **Loan system of record.** `facility` records keyed by `facility_id`, with `approval_id`, limit, term, repayment frequency, first payment date and `status`. - **Security and documents.** `security_item` and `document` records linked by `facility_id`, with lodged and registered flags. - **Payments.** `settlement_instruction` and `disbursement` records, linked by `facility_id`, with release status. - **Servicing view.** Read-only schedule and statement previews that appear only after booking.

Stable identifiers matter most. If `approval_id` and `facility_id` are carried through every table, a grader can follow a booking from decision to first statement.

Tool actions can mirror the work: `get_approval`, `list_conditions`, `create_facility`, `link_security`, `set_status`, `hold_file` and `return_to_credit`. Each call should write to an event log so graders can inspect order as well as outcome. Generated data should be checked for grounding before it is trusted as realistic.