Which records and relationships could a generated scheduling dataset contain?

A generated scheduling release can be organised around a small set of linked entities. The value lies in the links, because they let a grader verify that a change was applied consistently.

- **Agreement.** The obligation: parties, principal or contract value, rate or pricing terms, start date and permitted variations. - **Schedule.** A versioned header pointing to its agreement, with a status such as `active`, `superseded` or `cancelled`. - **Instalment line.** One dated amount with components (principal, interest, fees, or quantity for deliveries), a due date and a status. - **Payment or delivery event.** What actually happened: amount received, reversal, partial delivery, failed debit. - **Request.** A customer or counterparty ask, such as a date change, a skip or a split. - **Policy.** Rules with identifiers, thresholds and required approvals, referenced by the decisions that applied them. - **Approval and note.** Who decided what, when, and on which version.

Relationships worth generating on purpose include one agreement with several schedule versions, events that reference lines that were later superseded, and requests that conflict with a policy.

A release can also carry a calendar of business days and public holidays by jurisdiction, since due-date logic depends on it.

All of this is generated, and its realism depends on how well it is grounded in how such work runs. A buyer should inspect samples for plausibility and for any resemblance to real records before relying on them.