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 Desalination Filter Backwash Planning Workspace

Format
Code-aware
Lines
69
Sections
11
Linked challenge
Build a Desalination Filter Backwash Planning Workspace

Prompt source

Original prompt text with formatting preserved for inspection.

69 lines
11 sections
No variables
1 code block
## Build
Plan filter backwash windows from supplied inspection thresholds, durations, and available capacity. Show conflicts and reserve shortfalls before engineers approve a simulated maintenance schedule.

## User
Pretreatment Operations Engineer

## Workflow
1. Import synthetic filter readings, capacities, and fictional planning rules.
2. Flag readings above supplied inspection thresholds without inferring treatment effectiveness.
3. Schedule candidate windows while checking remaining capacity against supplied demand.
4. Export proposed windows, capacity conflicts, and unresolved readings for engineer review.

## Interface
Filter schedule table with capacity charts, editable assumptions, and an engineer review queue.

## Data
Create simplified synthetic filter records with pressure readings, fictional thresholds, planned durations, and parallel capacity. These are not WaterTAP model files.
Starter examples below are synthetic. They are not downloaded records.

## Source
[WaterTAP treatment modeling](https://raw.githubusercontent.com/watertap-org/watertap/main/README.md)
WaterTAP is an optional treatment-model integration reference. Supplied scheduling rules are fictional, not WaterTAP treatment recommendations.

## Tools
mastra-ai, pydantic, fastapi.
Use the selected framework for evidence-linked planning notes. Calculate capacity constraints in deterministic code.
Use a currently available model for planning explanations, not as an engineering solver.

## 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
- Flags readings above supplied thresholds.
- Uses only supplied durations and capacity.
- Blocks approval when capacity or duration is missing.
- Exports proposed schedules and conflicts.

## Starter Examples
```json
[
  {
    "input": {
      "filter_id": "MMF-01",
      "pressure_bar": 1.2,
      "fictional_threshold_bar": 1,
      "planned_duration_min": 15,
      "other_capacity_m3_h": 1000,
      "demand_m3_h": 800
    },
    "expected_output": {
      "threshold_exceeded": true,
      "candidate_duration_min": 15,
      "capacity_margin_m3_h": 200,
      "approval_required": true
    }
  },
  {
    "input": {
      "filter_id": "MMF-02",
      "pressure_bar": 1.2,
      "fictional_threshold_bar": 1,
      "planned_duration_min": 15,
      "other_capacity_m3_h": 500,
      "demand_m3_h": 800
    },
    "expected_output": {
      "threshold_exceeded": true,
      "candidate_duration_min": 15,
      "capacity_margin_m3_h": -300,
      "schedule_blocked": true,
      "approval_required": true
    }
  }
]
```

## Safety
Use synthetic records and offline scheduling. Do not command pumps or claim treatment performance.
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.