Skip to content
MirrorFirm

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

More on Loan booking