Skip to main content
Back to Prompt Library
implementation

Build the application

Inspect the original prompt language first, then copy or adapt it once you know how it fits your workflow.

Linked challenge: Build a District Water Pressure and Leak Outage Coordinator

Format
Code-aware
Lines
91
Sections
11
Linked challenge
Build a District Water Pressure and Leak Outage Coordinator

Prompt source

Original prompt text with formatting preserved for inspection.

91 lines
11 sections
No variables
1 code block
## Build
Evaluate municipal water distribution pipe isolation schedules during planned repair outages using hydraulic simulation models. Pinpoint low-pressure customer nodes and formulate fire-flow preservation plans.

## User
Water network utility planner

## Workflow
1. Ingest pipe break repair requests, valve isolation boundaries, and hydraulic node configurations.
2. Model network pressure fluctuations and fire hydrant delivery capabilities using WNTR simulation modules.
3. Identify critical demand nodes falling below minimum operational pressure during the planned shutdown window.
4. Generate a structured pipe outage playbook and tank water dispatch routing plan for district engineers.

## Interface
Interactive network topology map showing isolated pipes, impacted pressure zones, and tank water delivery routes.

## Data
Use WNTR example network INP files with synthetic customer demand patterns and maintenance tickets.
Starter examples below are synthetic. They are not downloaded records.

## Source
[Water Network Tool for Resilience](https://raw.githubusercontent.com/USEPA/WNTR/main/README.md)
Leverages WNTR hydraulic resilience and pressure-dependent demand simulation features to isolate network pipes.

## Tools
haystack, wntr, pydantic.
Searches municipal utility operating manuals and valve operating standards to assemble repair guidance dossiers.
Local or hosted LLM with standard Python runtime support for running hydraulic simulations.

## Deliverables
Submit runnable source, pinned dependencies, setup commands, a working interface, example outputs, and a recorded end-to-end demo. Include tests and an action log.

## Acceptance
- Executes a simulated valve isolation in WNTR to compute customer node pressure drops.
- Flags any junction node dropping below 20 psi during peak hourly demand intervals.
- Produces an isolation ticket specifying sequence of valve closures and contingency water dispatch points.

## Starter Examples
```json
[
  {
    "input": {
      "work_order_id": "WO-PIPE-782",
      "pipe_to_isolate": "P-104",
      "scheduled_start": "2025-07-10T22:00:00Z",
      "duration_hours": 4,
      "affected_valves": [
        "V-12",
        "V-15"
      ],
      "network_junction_pressures_psi": {
        "J-101": 42.5,
        "J-102": 38,
        "J-103": 24.1
      }
    },
    "expected_output": {
      "simulation_status": "FEASIBLE_WITH_CAUTION",
      "min_simulated_pressure_psi": 21.4,
      "critical_nodes": [
        "J-103"
      ],
      "fire_flow_maintained": true,
      "tanker_dispatch_required": false,
      "approved_by_hydraulics_lead": false
    }
  },
  {
    "input": {
      "work_order_id": "WO-PIPE-789",
      "pipe_to_isolate": "P-202",
      "scheduled_start": "2025-07-11T14:00:00Z",
      "duration_hours": 6,
      "affected_valves": [
        "V-30",
        "V-34",
        "V-39"
      ],
      "network_junction_pressures_psi": {
        "J-205": 31,
        "J-208": 18.2,
        "J-210": 15.4
      }
    },
    "expected_output": {
      "simulation_status": "UNACCEPTABLE_PRESSURE_DROP",
      "min_simulated_pressure_psi": 12.1,
      "critical_nodes": [
        "J-208",
        "J-210"
      ],
      "fire_flow_maintained": false,
      "tanker_dispatch_required": true,
      "approved_by_hydraulics_lead": false
    }
  }
]
```

## Safety
Simulation does not actuate municipal telemetry or send commands to physical SCADA controllers.
Use mock external writes. Require human review before any real deployment.

Adaptation plan

Keep the source stable, then change the prompt in a predictable order so the next run is easier to evaluate.

Keep stable

Hold the task contract and output shape stable so generated implementations remain comparable.

Tune next

Update libraries, interfaces, and environment assumptions to match the stack you actually run.

Verify after

Test failure handling, edge cases, and any code paths that depend on hidden context or secrets.