How could a generated task represent a correction that must be split across destinations?

A logistics accounts clerk finds that delivery cost `CST-2187` was posted entirely to one depot. Manifest `MAN-0412` shows that the run served two depots, and the cost allocation policy assigns shared transport charges according to recorded pallet movements.

The correction request asks for the charge to be moved to the second depot. The transport analyst supplies movement records showing that both depots received goods. The agent must recognise that moving the whole amount would replace one allocation error with another.

The resulting correction reduces the original depot allocation and creates a corresponding allocation for the second depot. The total cost remains unchanged. The proposed split links to the manifest, the movement records and the policy version used to calculate it. The reviewer can inspect the basis before approving the posting.

A MirrorFirm task pack could generate the manifest, depot references, movement quantities, allocation policy and expected correction components. Variants can include a missing movement record or a policy that excludes empty pallets. This teaches agents to derive the structure of an adjustment from the supplied business rule, rather than assuming every correction is a simple transfer between two complete amounts.