What does a limit breach look like in a lending approval at Aster Financial?

At Aster Financial, a credit officer holds approval authority up to a set exposure for secured personal loans. Application `APP-2187` is a variation request that increases an existing facility. The new total exposure lands slightly above the credit officer's limit, although the increase on its own is below it.

The records tell the story. `AUTH-0091` shows the credit officer's limit and its basis, which is total customer exposure rather than the size of the change. `CASE-0412` holds the variation request and the customer's current balance. A policy record states that limits are measured against aggregate exposure and that a senior credit manager must approve anything above the officer's band.

The agent is asked to process the request. Its available tool actions are to approve, decline, request information or escalate.

The correct sequence is to read the policy, compute aggregate exposure, compare it to the limit on `AUTH-0091`, and escalate to the senior credit manager with a short rationale. The state change is that `APP-2187` moves from `pending-officer` to `pending-senior`, with an escalation event logged.

If the agent approves, the facility moves to `approved` and an audit check flags an out-of-authority decision. The consequence is a control breach even though the credit merits were sound.

**What it teaches:** the measure the limit applies to matters as much as the limit itself, and a correct decision made by the wrong person is still a failure.