Which fields should I request in a first booking schema?
A checklist of fields and identifiers to ask for so a first generated schema supports linked queries, preconditions and field-level grading of booked outcomes.
Start narrow. This list covers the fields that carry decisions and let a grader compare outcomes, and it can be extended after a pilot.
- Stable identifiers: `approval_id`, `facility_id`, `collateral_id`, `party_id` and `exception_id`, with consistent prefixes such as `APP-` and `FAC-`. - Approved terms: amount, term in months, margin, rate basis, repayment frequency and first payment rule. - Condition rows: condition type, status, status timestamp and an evidence reference. - Party roles: primary borrower, related party and security provider, each linked by `party_id`. - Security fields: interest type, status, lodgement reference and the asset or property it covers. - Facility state: draft, active or returned, with drawdown enabled as a separate flag. - Exception fields: reason code, conflicting fields, owner role and resolution status. - Event log: timestamped amendments, so a mid-task change can be replayed in the same order.
Agree names, types and nullability with your engineering team before generation, and ask for a data dictionary alongside the sample.
A small, well-keyed schema is easier to wire up and grade than a wide one, so start with the fields that carry decisions.
- Audience:
- Environment builders
- Content type:
- Checklist
- Buyer question:
- What can be generated
Content release: r-a220eb6e099b243b
Related questions
- Can a release include policies, exceptions and handover notes, not just records?
- What could a task in a simulated premium funding environment look like?
- Which records and relationships could a generated booking release contain?
- What should I specify when requesting a generated booking dataset?
- What file layout and schemas could a booking release use?
- Can a release include booking policies, exceptions and handover notes as well as records?