What might a generated task look like for a fleet finance facility with a balloon payment?

A logistics operator has been approved for `APP-4410`: asset finance of 640,000 across three prime movers, 60 monthly repayments, with a residual of 120,000 payable at the end of term. The approval record holds the residual in the `balloon_amount` field. The asset register lists the three vehicles by `ASSET-8801`, `ASSET-8802` and `ASSET-8803`.

The generated task gives the agent the approval, the asset register extract and the loan system tools. The expected end state is a single facility, `FAC-5120`, with three linked asset records, a repayment schedule that amortises to the residual, and a final balloon line dated at maturity.

A weak agent enters the term and limit but leaves the residual blank. The system accepts the booking and generates a fully amortising schedule with higher instalments. The first statement overstates the amount due, the customer disputes the direct debit, and the servicing team opens `CASE-0412` to correct the schedule and refund the difference.

**What it teaches.** The task checks a single field with a large downstream effect. It also checks links, because a facility with one asset instead of three would pass a limit check but fail security coverage. The grader compares the schedule, the balloon line and the asset links against the expected state.