Skip to content
MirrorFirm

How does escalation connect to the other records in a lending process?

Escalation is a set of links between application, authority, referral, note, decision and task records, and each link carries state changes that an agent or grader can follow.

In a generated lending environment, escalation is a link between records rather than a standalone table. A useful release makes those links explicit so a model or agent can follow them.

Typical relationships:

- `application` (`APP-2187`) holds requested amount, product and current status - `authority_matrix` holds role, product and maximum exposure per decision type - `referral` (`REF-0931`) points to `application_id` and carries `from_role`, `to_role`, `reason_code` and `created_at` - `handover_note` points to `referral_id` and carries recommendation text and an evidence list - `decision` points to `referral_id` with outcome, conditions and the deciding role - `task` records point back to the application and are created by the decision

The key integration detail is **which record changes state when**. Creating a referral should move the application to an escalated status and remove the decision task from the original reviewer. A decision record should close the referral and, if conditions exist, create tasks.

For linked facilities, an `exposure_group` table lets combined exposure trigger the referral even when each facility is under the limit. Ask for that join if you want to test whether a model aggregates before checking authority.

Formats are typically JSONL per table with stable identifiers, and Parquet for larger tables. Confirm identifier style and foreign-key coverage in a sample before scoping further.

Explicit links and state changes let a model or grader trace an escalation from trigger to follow-up task.

Audience:
Model labs
Content type:
Integration
Buyer question:
What it is and why it matters

Content release: r-a220eb6e099b243b

More on Credit escalation