Skip to content
MirrorFirm

How would a task pack encode a duplicate connection request?

A utility connection task pairs two cases for the same lot, where the second corrects the first, and defines the exact links, field changes and queue move expected.

A task pack for a utility's new connection requests includes CASE-0412, lodged online by a property developer for a new unit. Forty minutes later, CASE-0415 arrives by email for the same lot number with a different contact and a corrected meter location.

The environment state holds both cases as OPEN, a parcel record for the lot, and a routing policy that sends connections with a site inspection flag to the network planning queue and all others to the standard connections queue. CASE-0412 has the inspection flag unset; CASE-0415 corrects the meter location, which sets it.

The expected behaviour: the intake agent links CASE-0415 to CASE-0412 as an amendment, merges the corrected location into the earlier case, sets the inspection flag, moves the case to the network planning queue, closes CASE-0415 with a reason of DUPLICATE_AMENDMENT, and notes the change for the network planner.

The consequence of failing is concrete. If the agent treats the second email as a new case, two cases compete for one lot, the standard queue schedules a connection without inspection, and the network planner finds the problem only on site.

**What it teaches:** a generated pack should encode exceptions with a defined correct answer, including the link between records, the field changes and the closing reason, so a grader can check each part separately.

A good task encodes the exception with a defined correct answer, so each part of the agent's behaviour can be graded separately.

Audience:
Agent developers
Content type:
Scenario
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Application intake