Skip to content
MirrorFirm

What would a generated utility connection case contain, from intake to resolution?

A generated electricity connection case shows documents, a policy, a conflict between site details, a request, and a resolution recorded as state changes.

A connections coordinator at a regional electricity distributor receives case `CONN-0412` for a new commercial supply.

**Policy `POL-CONN-11` requires:** a site plan, proof of land ownership or lessee consent, an electrical contractor's certificate of intent, and an authorised signatory declaration.

**Documents in the file:**

- `DOC-8821`, a site plan showing lot 14 - `DOC-8822`, a lease consent letter naming lot 41 - `DOC-8823`, a contractor's certificate, dated and signed - no signatory declaration

The generated record marks two defects. The consent letter names a different lot from the site plan, which is a consistency conflict, and the declaration is absent. The gold decision is **request**, not escalate, because both defects can be resolved by the applicant.

The gold request `REQ-1175` goes to the applicant's contractor and lists two items, each linked to a requirement: confirm or reissue the consent for lot 14, and supply the declaration. The case status moves from Received to Awaiting applicant.

The scenario then includes a reply with a corrected letter but no declaration. The gold next step is a second, narrower request, and the case stays in Awaiting applicant.

**What it teaches:** partial resolution is common, the model must track which gaps remain open, and a generated environment can store this as state across turns rather than a single prompt.

The case shows the level of detail a task pack can carry, including conflicting evidence that forces a specific request.

Audience:
Model labs
Content type:
Scenario
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Document sufficiency