How should recurring review schedules appear in an evaluation environment?

A generated review environment can represent recurrence separately from individual review runs. A schedule record could contain `schedule_id`, `subject_id`, `cadence_rule`, `timezone`, `next_due_at` and `schedule_status`. Each run then links back through `schedule_id` and records its own `review_id` and `triggered_at`.

This separation matters when a scheduler retries an event or an agent encounters an overdue item. Repeated delivery of the same trigger should not silently create independent obligations. A task can require the agent to recognise an existing run before opening another.

An interface could expose `list_due_reviews`, `get_schedule` and `open_review`, with the evaluation clock fixed at episode start. Boundary cases can place the due time near a local date change, making timezone handling part of the task rather than an implicit assumption.

A reset can restore both the schedule and its run ledger. Evaluation hooks can then check premature creation, missed triggers and duplicate obligations independently of review judgement. Buyers should specify which scheduling semantics the generated environment models, including what happens when a scheduled date falls outside operating days.