Skip to content
MirrorFirm

Which entities should I ask for in a schedule dataset or environment?

This checklist lists the entities and attributes worth requesting so that schedule tasks have enough linked state to be graded on consequences as well as edits.

Ask for enough linked state that a change can be followed from the action to everything it affects. These are the entities most buyers will want to name in a request.

- Plans and instalments with sequence, due date, amount, fee and status on every line. - Payments with allocation links, including part-payments, reversals and overpayments. - Versioned policy records with effective dates and the roles allowed to approve exceptions. - Customer or counterparty context such as segment, hardship or dispute markers that change what is allowed. - Communications triggered by changes, including reminders, notices and confirmations. - An event log with actor, action and before and after references. - Task definitions with a starting snapshot, a goal statement and an expected end state or invariants. - Distractor cases, such as near-identical plans or requests that sound urgent but fall outside policy.

Not every item is needed for a first pass. Pick the ones your graders depend on, and note which fields you would map to your own schema.

All records are generated, so include in the request a way to review how they were grounded and what disclosure checks apply.

Request the linked entities up front, because missing links are the most common reason a schedule task cannot be graded properly.

Audience:
Environment builders
Content type:
Checklist
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Repayment scheduling