What would a generated utilities connection task contain?

A residential electricity retailer accepts application `APP-6024` for a new connection. The task pack gives the model the application, the retailer's identity-matching policy and a search tool over the customer base.

The starting state holds two candidate records. `CUS-8841` has the same name and a previous address. `CUS-9120` has the same mobile number but a different date of birth. The policy says a match needs two agreeing identifiers, and a single agreeing identifier requires a review case.

The site record `SITE-2217` shows a meter that is already linked to another customer from a prior tenancy. A billing hold flag is set on the site until a move-out reading is recorded.

The expected path is as follows. The model finds that neither candidate meets the two-identifier rule, creates a new customer `CUS-9377`, opens `CASE-1186` to resolve the possible duplicate and sets the service to `awaiting_reading`. It does not activate billing.

**What a grader checks:** no merge occurred, the new customer is linked to the application, the case exists with the right reason code, and the service status matches policy.

**What it teaches:** a task pack can encode a rule, a trap and a clear end state, so a model's choice between merging, creating and escalating is scored on records, not prose.