Which records and relationships can an escalation dataset contain?

A generated escalation dataset can be built around the objects a credit team touches, with the links between them kept explicit.

**Policy objects.** An authority matrix by role, product and risk grade; policy clauses with trigger conditions; and exception rules, such as a temporary uplift granted to one reviewer.

**Party and exposure objects.** Applicants, related entities, facilities and balances, so that aggregate and connected exposure can be calculated rather than asserted.

**Case objects.** Applications, review notes, referral packages, attachments and a time-ordered event history showing who held the case and when.

**Roles and queues.** Reviewer tiers, delegates, absent-reviewer rules and the queues a referred case lands in.

**Outcomes.** Senior decisions of approve, decline, approve with conditions or return for information, each with a rationale.

Because every number can be derived from linked records, a task pack can state the correct routing and check it by computation. Seeds can vary amounts, tiers and relationships so that a model cannot memorise one case.

The output is generated, informed by how businesses handle delegated authority. It carries no real customer data, but buyers should still inspect samples for grounding gaps and for any content that resembles identifiable material. Scope the object list in a pilot rather than assuming all of it is included.